JIRA is not a big problem. Say for example that the 3.1.1 release was abandoned due to some problem, you would simply rename the version in JIRA from 3.1.1 to 3.1.2.
On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <strub...@yahoo.de> wrote: > I think it's mainly because the maintenance and housekeeping costs on the > JIRA front and others which use the version nr as reference. > > > Imagine that you would need to move all the JIRA tickets which got marked as > fixed in a certain release as well. Otherwise the release notes would be > broken - or would need to get maintained manually. > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Fred Cooke <fred.co...@gmail.com> >> To: Maven Developers List <dev@maven.apache.org> >> Cc: >> Sent: Saturday, 14 September 2013, 21:51 >> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT >> >> 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 >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
