I believe the strict policy only applies to master branch. The entire concept is different anyway, it's just a label. Leave it there, it costs nothing except name space. The persistent try-1 try-2 etc tags will also get mirrored into perpetuity anyway. Master should likely be left alone during a release such that a ff is possible. If changes are required from failed vote, they are made on master, then a new branch is forked off, and try again. If not waiting for that, a full merge would be OK too, there would be no conflict even if the POM had changed in other places. I personally prefer to avoid them where possible, though.
On Sat, Sep 14, 2013 at 9:15 PM, Mark Struberg <strub...@yahoo.de> wrote: > The question is not whether you do this on a branch or not, but only where > to push this branch to and where people do the validation for the VOTE. > > GIT repos at the ASF have a strict history-rewrite policy and don't allow > to ditch stuff. I'm not 100% sure myself if this is also for deleting > upstream branches on the central repo. > > What might be a solution would be to have a 2nd 'sandbox' GIT repo for > each of our 'main' GIT repos for a project. The master of this sandbox GIT > repo would automatically get replicated from the main repo and would deny > any push to master otherwise. This repo could be used to create temporary > playground like feature branches etc. History rewrite and deleting branches > and tags would be allowed on this repo. Might be a way to tackle this on > ASF hardware without forcing people to use another repo hosting. > > 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, 20:48 > > Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT > > > > 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 > >> --------------------------------------------------------- > >> > >> > >> > >> > >> > >> > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
