FFS, Mark. You know better than to argue with me about Git, don't you? :-p Label in a file system = hard link. Garbage collection (space available) = no hard links to inodes. Cut the shit man :-p
Nit picking is a BIG understatement :-p Fred. On Sat, Sep 14, 2013 at 11:12 PM, Dennis Lundberg <[email protected]>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. > > 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: > >>> > >> 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 > >> <[email protected]> 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 > >> <[email protected]> > >>> > >> 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: [email protected] > >>> > >> For additional commands, e-mail: [email protected] > >>> > >> > >>> > > > >>> > > > >> --------------------------------------------------------------------- > >>> > > To unsubscribe, e-mail: [email protected] > >>> > > For additional commands, e-mail: [email protected] > >>> > > > >>> > > >>> > Thanks, > >>> > > >>> > Jason > >>> > > >>> > ---------------------------------------------------------- > >>> > >>> > >>> > >>> -- > >>> Sent from my phone > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
