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
