On 16 September 2013 12:26, Fred Cooke <fred.co...@gmail.com> wrote: > Version ranges are extremely useful for this case: lib 0.2.4 >> 0.3.0 non > inclusive where lib has a guaranteed stable API with only non-breaking bug > fixes and additions. There are other uses, too. I sincerely hope it's never > dropped or broken. > > What I want to see, and it would be a change that requires a POM specification change, is that version ranges are never provided without a "recommended" version.
So I would see something like 1.0.3:[1.0.0,1.1.0),[1.1.1,2.0.0) as meaning use 1.0.3 but it should work with anything >= 1.0.0 and < 1.1.0 or >=1.1.1 but < 2.0.0 (presumably 1.1.0 is known broken) You could even allow meta-labels when the pom itself is a -SNAPSHOT version, e.g. SNAPSHOT:[1.0.0,1.1.0),[1.1.1,2.0.0) LATEST:[1.0.0,1.1.0),[1.1.1,2.0.0) STABLE:[1.0.0,1.1.0),[1.1.1,2.0.0) The first says pick the highest version that is in the range and -SNAPSHOT is allowed The second says pick the highest release version that is in the range, -SNAPSHOT is not allowed The third says pick the lowest release version that is in the range, -SNAPSHOT is not allowed When the release plugin runs, it would replace the SNAPSHOT, LATEST or STABLE with the most appropriate corresponding release version *at the time of release*. Thus release builds are reproducible always and developers would not need to worry about updating poms. Some tooling or CLI options on Maven could allow for switching a build from the meta-label in the POM to a specific meta-label so that CI builds could probe the extremes easily... and I am sure we could provide additional tooling to probe data points within the various ranges. But I would like to see naked ranges dropped from release builds as they lead to irreproducible release builds, which is a very bad thing > On Mon, Sep 16, 2013 at 10:09 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 16 September 2013 08:20, Jörg Schaible <joerg.schai...@scalaris.com > > >wrote: > > > > > Hi Jason, > > > > > > Jason van Zyl wrote: > > > > > > > When a release fails like this it is annoying to have to rev back the > > > > version of the POM. I'm not sure who flipped the versions in the POM > > and > > > > while it's a little more visible to see what you're moving toward I > > > prefer > > > > the pattern of: > > > > > > > > 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT > > > > > > > > I know this may not be obvious to the casual observer as they may > think > > > > 3.1 is next, but I'm personally fine with that. > > > > > > That's quite funny, because we did this years ago when we started using > > M2 > > > and then we were told here in the list it is an anti-pattern, because > > 3.1- > > > SNAPSHOT is always minor for the dependency resolution than any 3.1.x > > > release. > > > > > > > > That was before it was decided that version ranges were a bad plan. If we > > were using version ranges then this would indeed be crapulent > > > > > > > - Jörg > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
