2009/10/16 Peter Janes <[email protected]> > On 16/10/09 11:45 AM, 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. >> > > OK, I guess what I really need is something like HIGHEST-RELEASE and > HIGHEST-SNAPSHOT. I don't think version ranges will support this case, as > the version in use could be anything in the range; RELEASE/LATEST would work > locally (since we generally perform incremental releases rather than > patches) but not in the general case. >
version ranges always resolve the highest version in the range IIRC [The issue is whether they resolve -SNAPSHOTs... but as MVERSIONS-19 shows, there is a "bug" in core that "prevents" ranges from resolving -SNAPSHOTs] > > What I want to use this for is to drive continuous/automated higher-level > testing, e.g. integration tests, system tests, upgrade tests, etc., as part > of a wider lab deployment scenario. This wouldn't produce artifacts per se, > it would just install the products and run tests against them. So instead > of using the latest versions of foo-api and bar-api, I want to verify that > the latest versions of Foo and Bar work together, i.e. the integration-test > project would depend on Foo:HIGHEST-RELEASE and Bar:HIGHEST-RELEASE. > > 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 ;-) >> > > You're right, they're completely wrong for the purpose and I don't see how > they'd ever be useful as implemented today. > > 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 >> >> ;-) >> > > Agreed. Especially since they're not supported consistently, and (as you > mentioned) they don't behave the way their names suggest. Since Sonatype > are so heavily involved in developing Maven I kind of took the book as the > expected behaviour, since there's very little documentation on those > pseudo-versions elsewhere. > > -- > Sometimes the Universe needs a change of perspective. > --J. Michael Straczynski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
