Stephen Connolly wrote:
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 ;-)


What would be nice IMO is if we could have the best of both worlds ;). In my local build I often want just the latest version whether it breaks my build or not. But in my deployed POMs I would *never* want LATEST or RELEASE to show up, even for a snapshot release, because they are meaningless at that point.

In a perfect build system the process would allow my local system to use things like LATEST and version ranges, but those things would be automatically resolved at some point before deployment. That way, once I deploy I know that all the necessary information to reproduce the build is there.

The versions-maven-plugin helps with this issue, but it would be better if this functionality was build into Maven instead of being an extra step.




 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



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to