No, a tag and a branch is not only just a label.
GIT internally has a kind of garbage collection. And once some commits are not referenced by another tree they are subject to be dropped from the repo on a re-pack which might happen on git-prune or git-gc. But that's nit picking. The real problem is that our main repo is always pulled to tons of downstream repos. And they don't forget anything. This is why I suggest the 2nd repo which is a kind of throw-away repo which is not intended for downstream usage. I fully agree with you that master should be left alone until the VOTE has succeeded. LieGrue, strub >________________________________ > From: Fred Cooke <fred.co...@gmail.com> >To: Maven Developers List <dev@maven.apache.org>; Mark Struberg ><strub...@yahoo.de> >Sent: Saturday, 14 September 2013, 21:43 >Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT > > > >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 >> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
