In DeltaSpike I always push the release branch + tag to my personal github repo. After the VOTE did succeed I push the exact sha1 upstream to the ASF repo.
This is not perfect but it's good enough imo as the parent commit is verifiable coming from the ASF upstream repo. Plus people can check that the tag they voted on is exactly the same I push to the ASF repo later. The only minor downside is that you really need to merge in the pom version upgrade to the upstream master branch which might have changes already. LieGrue, strub ----- Original Message ----- > From: Jason van Zyl <ja...@tesla.io> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Saturday, 14 September 2013, 20:47 > Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT > > 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
