Why as long as you don't push the tag, there's no big deal. Pushing the tag is when problems appear... In any case I'd prefer to just skip failed version numbers... Though I was voted down last time that came up, and given I'm not running too many releases at the moment, I don't see my opinion as being heavyweight on that subject... Version numbers are cheap and we've had borked releases before (eg critical IMHO bugs in 2.1.0, 2.2.0 and 3.1.0...) so I don't buy the "what if a user checks out a tag that was not released" argument.
In my opinion we need a release status page anyway, eg stating whether specific versions are considered stabilising, stable, retired or advised not to be used... Such a page would remove the need for recycling version numbers *and* provide benefit to users at the same time. But I will leave it for others to fight the relative costs of version numbers (given the infinite supply) against making sure JIRA release notes and javadoc @since tags (which is stupid, @since 3.2.3 means it should be there in the 3.3.0 release that 3.2.3 became, so no fix strictly required) are correct and saving the risk that a user checks out an unreleased tag and tries to build that from source and then starts trying to raise bugs against a non-exist any version! On Saturday, 14 September 2013, Jason van Zyl wrote: > We need a slight modification of this strategy because the changes need to > be pushed somewhere so that people can examine the tag if they want during > the release. I can't keep it on my machine until the vote passes. > > On Sep 14, 2013, at 2:20 PM, Mark Struberg <strub...@yahoo.de> wrote: > > > +1, that's what we also use in DeltaSpike and dozen other projects. > > pushChanges=false + localCheckout=true for the win! > > > > LieGrue, > > strub > > > > > > > > > > ----- Original Message ----- > >> From: Arnaud Héritier <aherit...@gmail.com> > >> To: Maven Developers List <dev@maven.apache.org> > >> Cc: > >> Sent: Saturday, 14 September 2013, 19:45 > >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT > >> > >> G ood practice too. I'm using it also at work and we are doing our > >> releases on dedicated branches. > >> > >> --------- > >> Arnaud > >> > >> Le 14 sept. 2013 à 19:30, Fred Cooke <fred.co...@gmail.com> a écrit : > >> > >>> You're in Git now. You don't *have* to push your tag and release > >> commits up > >>> to the public world until AFTER you've checked they're OK. Or by > >> failed > >>> release do you mean voted down? They could live on branches until set > in > >>> stone, then merge --ff-only into master at that point, if so. > >>> > >>> > >>> On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <ja...@tesla.io> > >> 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. > >>>> > >>>> Especially after a failed release because then I don't have to go > >> change > >>>> all the POMs (whether rolling back manually, using the release > >> rollback, > >>>> the version:set command, or whatever else). It's much easier to > >> just fix > >>>> what's necessary and carry on. > >>>> > >>>> Unless anyone objects I would like to go back this pattern, what I > >>>> previously had, because it's far easier to manage. Ideally it might > >> be nice > >>>> if all the tools understood 3.1.z-SNAPSHOT but they don't an in > >> lieu of > >>>> that I would prefer not to diddle POMs after a failed release. > >>>> > >>>> Thanks, > >>>> > >>>> Jason > >>>> > >>>> ---------------------------------------------------------- > >>>> Jason van Zyl > >>>> Founder, Apache Maven > >>>> http://twitter.com/jvanzyl > >>>> --------------------------------------------------------- > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > Thanks, > > Jason > > ---------------------------------------------------------- -- Sent from my phone
