Ok, we need to figure how this works together with all the auto-mirrors around (github/asf/maven, etc).
Are we d'accord that we must _not_ do releases on master but always create a temporary branch for each release (and then merge back to master after the vote passed) ? LieGrue, strub ----- Original Message ----- > From: Kristian Rosenvold <kristian.rosenv...@gmail.com> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Friday, September 21, 2012 10:33 AM > Subject: Re: Scm, Surefire, Wagon migrate to git (please check) [was Plan for > git migration] > > You don't really "crash" anything, but if the tag is rewritten you > have to delete the local tag to actually get the updated reference to > the tag. > > The authorative repo is correct, but there may be some clones out > there that are unaware of the failed release and the moved tag. > > I still think the benefit of moving the tag > just tagging locally > (and hence missing tags). > > Could we introduce something like subtagging ? If the official release > tag is "xyz_plugin_1.2.3", could we have the release plugin tag the > first version as "xyz_plugin_1.2.3_0" and just automatically advance > the tag for each re-release ? Then we *could* have some automated step > in the post-vote process burniung the final release number based on > highest available subtag (and delete the subtags) ? > > I suppose a similar post-vote tool could also just push the local > release tag to the repo, so I may be complicating things.....? > > Kristian > > > > > > > > > > > > 2012/9/20 Mark Struberg <strub...@yahoo.de>: >> Hi folks! >> >> The problem is the rollback. >> In DeltaSpike we do _not_ push now. deleting a tag on one repo is not a > problem, but you would crash all downstream clones as re-trying a release is > basically a history rewrite. >> >> In DeltaSpike I do the release locally and push the tag + release branch to > my github clone (or any other public repo you like). >> After the VOTE passes I merge it to master and push it to the ASF canonical > repo. >> >> Not perfect neither, but worked far better than history rewrites at least > ;) >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Kristian Rosenvold <kristian.rosenv...@gmail.com> >>> To: Maven Developers List <dev@maven.apache.org> >>> Cc: >>> Sent: Thursday, September 20, 2012 4:56 PM >>> Subject: Re: Scm, Surefire, Wagon migrate to git (please check) [was > Plan for git migration] >>> >>> I just checked and there is no general blocking for deleting tags. We >>> should definitely push as part of release plugin. Tags ar cheap. >>> >>> Kristian >>> >>> >>> 2012/9/20 Olivier Lamy <ol...@apache.org>: >>>> 2012/9/20 Mark Derricutt <m...@talios.com>: >>>>> Olivier, >>>>> >>>>> I'm not checked yet ( not thru lazyness, but thru > buzyness, and >>> shooting this email just as I think of it ), in all my local maven/git > projects >>> I set in the maven-release-plugin configuration: >>>>> >>>>> <pushChanges>false</pushChanges> >>>>> <localCheckout>true</localCheckout> >>>>> >>>>> to prevent any upstream/origin pushes during release ( there > may not BE >>> an origin/remote yet ). There was some discussion either on here, or in > JIRA ( >>> not sure off hand which ) about making these options the default for > any of the >>> supported distributed version control systems. >>>>> >>>>> Does anyone know if this was done? Should these options be > mandated as >>> a standard practise for maven+git conversion? >>>> >>>> No release yet. >>>> But regarding <pushChanges>false</pushChanges>, I > remember we >>> used on >>>> jenkins side and everybody missed the manual step (push the tag) > when >>>> released. So we moved to true. >>>> BTW it's something to discuss. >>>> Maybe pushing the tag once release vote passed ? >>>> I remember some discussions on ASF infra for blocking of tag > deletion >>>> (I don't know if this has been applied on the final infra) > because we >>>> sometimes delete tags if the release vote fail. >>>> I can test creating a fake tag and try delete it :-) >>>> >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> On 20/09/2012, at 1:40 AM, Olivier Lamy > <ol...@apache.org> wrote: >>>>> >>>>>> BTW I have started a page here: >>>>>> http://maven.apache.org/developers/conventions/git.html >>>>>> >>>>>> we could put some git tips and more conventions. >>>>>> >>>>>> >>>>>> 2012/9/18 Arnaud Héritier <aherit...@gmail.com>: >>>>>>> My remarks about these repos : >>>>>>> * trunk will have to be renamed master (I'm not > sure if >>> we'll go further >>>>>>> like using the git workflow with the develop branch to > keep >>> master as >>>>>>> stable as possible - In any case I would recommand to > follow a >>> convention >>>>>>> fix/XXXX, stable/A.B.C, feature/ZZZZ to organize > branches) >>>>>>> * A strange thing I didn't have in my company > repositories >>> I recently >>>>>>> migrated is the commit/tag (copy for tag) for each > release done >>> by the >>>>>>> release plugin. I don't know if it is a different > setting >>> in the plugin or >>>>>>> something cleaned by filters I applied in the SVN > -> GIT >>> migration we did >>>>>>> * Some strange branches to cleanup ? ASF, APACHE or by > user >>> (trygvis, >>>>>>> evenisse ...) >>>>>>> >>>>>>> That's all what I see for now. >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> >>>>>>> On Tue, Sep 18, 2012 at 8:29 PM, Arnaud Héritier >>> <aherit...@gmail.com>wrote: >>>>>>> >>>>>>>> I Will test them. Will they keep these ugly URLs > git-wip-us >>> in the >>>>>>>> future ? I'm not a fanatic but I would prefer > to have >>> something stable >>>>>>>> to put in our POMs for releases. I know that we > don't >>> use often scm >>>>>>>> infos after the release but it is sad if we know > that >>> they'll be >>>>>>>> discontinued in a near future. No ? >>>>>>>> >>>>>>>> Le 18 sept. 2012 à 19:23, Olivier Lamy >>> <ol...@apache.org> a écrit : >>>>>>>> >>>>>>>>> Repositories has been migrated to: >>>>>>>>> * >>> https://git-wip-us.apache.org/repos/asf/maven-surefire.git >>>>>>>>> * >>> https://git-wip-us.apache.org/repos/asf/maven-wagon.git >>>>>>>>> * > https://git-wip-us.apache.org/repos/asf/maven-scm.git >>>>>>>>> They are currently read only. >>>>>>>>> Content looks good. >>>>>>>>> If nobody complains, I will ask to move to rw > mode >>> tomorrow. (in 24H) >>>>>>>>> >>>>>>>>> 2012/9/18 Olivier Lamy > <ol...@apache.org>: >>>>>>>>>> Hi >>>>>>>>>> See >>> https://issues.apache.org/jira/browse/INFRA-5266 >>>>>>>>>> Those tree svn paths will be readonly now > for >>> migration. >>>>>>>>>> >>>>>>>>>> 2012/9/12 Olivier Lamy > <ol...@apache.org>: >>>>>>>>>>> Hi Folks, >>>>>>>>>>> So the vote passed, now it's time > for >>> volunteers to use their fingers >>>>>>>> :-). >>>>>>>>>>> I have started a page [1] for ETA of > migration >>> (note the Volunteer >>>>>>>>>>> column :-) ) and for discussion on > some stuff >>> (plugins shared) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -- >>>>>>>>>>> Olivier Lamy >>>>>>>>>>> Talend: http://coders.talend.com >>>>>>>>>>> http://twitter.com/olamy | >>> http://linkedin.com/in/olamy >>>>>>>>>>> [1] >>> https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Olivier Lamy >>>>>>>>>> Talend: http://coders.talend.com >>>>>>>>>> http://twitter.com/olamy | >>> http://linkedin.com/in/olamy >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Olivier Lamy >>>>>>>>> Talend: http://coders.talend.com >>>>>>>>> http://twitter.com/olamy | > http://linkedin.com/in/olamy >>>>>>>>> >>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: >>> dev-h...@maven.apache.org >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ----- >>>>>>> Arnaud Héritier >>>>>>> 06-89-76-64-24 >>>>>>> http://aheritier.net >>>>>>> Mail/GTalk: aherit...@gmail.com >>>>>>> Twitter/Skype : aheritier >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olivier Lamy >>>>>> Talend: http://coders.talend.com >>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>> >>>>>> >>> --------------------------------------------------------------------- >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Olivier Lamy >>>> Talend: http://coders.talend.com >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>> >>>> > --------------------------------------------------------------------- >>>> 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 >>> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
