Fair call.
On Mon, Sep 16, 2013 at 1:39 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 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 > > > > > > > > > > > > > >
