2009/10/16 Peter Janes <[email protected]> > On 15/10/09 05:45 AM, Stephen Connolly wrote: > >> These are very dangerous versions to suggest use of. >> > > ...but there *are* use cases for them.
When your use case results in a completely unpredictable build... no thank you. For dependencies, use version ranges. For plugins, you should always lock down the version. That is best practice, and that is what we should support. Seriously, consider the following scenario... I release foo-api in the following sequence @1pm: 1.0 @2pm: 1.1 @3pm: 1.2 @4pm: 2.0 @5pm: 2.1 @6pm: 1.3 @7pm: 2.2 @8pm: 3.0 @9pm: 1.4 @10pm: 2.3 @11pm: 1.0.1 If you depend on foo-api:RELEASE, then depending on when you do your build you will get a random version, e.g. @8:15pm you will build with version 3.0, @9:05pm you will be building with 1.4, and @10:59pm you'll get 2.3, while @11:01pm you get 1.0.1!!! If you have a CI system deploying snapshots as you go, and following each of the dev streams, then LATEST is essentially completely _RANDOM_ as far as a developer is concerned, since the version you get purely depends on the last version deployed by the CI system. If you can present a usecase where this is _exactly_ what you want, then fine, but I have yet to see such ;-) > > > These are deprecated and are only "special" versions when considering >> plugins... and they do not behave as you think they behave. >> > > For what it's worth, the Sonatype Maven book says that "When you depend on > a plugin *or a dependency*, you can use the version value of LATEST or > RELEASE."[1] We need to fix the sonatype book then ;-) > However, I'm not aware of any released version of Maven or any plugin that > actually treats dependencies this way; Mercury, tested through > versions-maven-plugin, doesn't appear to either. (But I'd love to be proven > wrong!) > > [1] > http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html#pom-relationships-sect-latest-release > > -- > Sometimes the Universe needs a change of perspective. > --J. Michael Straczynski > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -Stephen
