On Saturday, 14 September 2013, Dennis Lundberg wrote: > 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.
Exactly. Not a problem if you ask me... The only one I can think of if the javadoc @since tags and even without skipping versions they can end up at a unreleased version label, plus they are just a >= which will be valid anyway > > On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg <[email protected]> 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 <[email protected]> > >> To: Maven Developers List <[email protected]> > >> 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 < > >> [email protected]> 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 <[email protected]> > >> 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 <[email protected]> > >>> > >> To: Maven Developers List <[email protected]> > >>> > >> Cc: > >>> -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected] <javascript:;> > > -- Sent from my phone
