Branches.
On Sat, Sep 14, 2013 at 8:47 PM, Jason van Zyl <ja...@tesla.io> 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 > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > > > > > > >
