> 
> Well I'm hoping to refactor v-m-p real soon now to split out 
> the version
> checking stuff as an api .jar which would allow writing an 
> m-enforcer-p rule
> to allow you to force projects to only release with the 
> latest version of
> internal dependencies

Great, I'm looking forward to that!

> 
> 
> >
> > >
> > > If we remove -SNAPSHOT from dependencies which have not been
> > > released then
> > > we'd break your build.
> >
> > This is true... so you would suggest that for instance project A is
> > released, then the parent POM is adapted using 
> versions:use-releases for
> > project A; then project B is released, and the same happens again?
> > In that case (as I was already thinking), the parent POM 
> has to be replaced
> > in the repo every time a project is released. Which is kind 
> of a hack, but I
> > don't see any other way... I wonder what "the Maven way" is 
> for that.
> >
> 
> I would suggest in such a case not to use a parent pom to 
> force versions, or
> else to release everything in one go from the parent pom... 
> or else accept
> that the parent pom (which is really an integration pom) will 
> get a lot of
> churn.
> 
> The "Maven Way" as I see it is to let projects define their 
> dependencies.
> with the versions-m-p you now have reports to tell you when 
> the  project is
> not using the latest versions... and not using the latest version of
> something is not a crime... it might be more stable.... for 
> example the
> latest version of Hudson is not always the most stable (though the new
> weekly release cycle is improving that)

Well, for external dependencies you may not want the latest, greatest, but for 
internal projects you definitely want your projects to depend on the latest 
version. Unless you want to support several versions in parallel, which most 
developers don't want to  :-)

Anyway, thanks for your insights!

Best regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to