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 <[email protected]>: > 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 <[email protected]> >> To: Maven Developers List <[email protected]> >> 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 <[email protected]>: >>> 2012/9/20 Mark Derricutt <[email protected]>: >>>> 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 <[email protected]> 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 <[email protected]>: >>>>>> 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 >> <[email protected]>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 >> <[email protected]> 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 <[email protected]>: >>>>>>>>> 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 <[email protected]>: >>>>>>>>>> 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: >> [email protected] >>>>>>>> For additional commands, e-mail: >> [email protected] >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ----- >>>>>> Arnaud Héritier >>>>>> 06-89-76-64-24 >>>>>> http://aheritier.net >>>>>> Mail/GTalk: [email protected] >>>>>> Twitter/Skype : aheritier >>>>> >>>>> >>>>> >>>>> -- >>>>> Olivier Lamy >>>>> Talend: http://coders.talend.com >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>> >>>>> >> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
