I agree on skipping failed versions! I was avoiding the topic because it seemed popular opinion was to re-spin endlessly like a child's spinning top.
On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 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 >
