2012/9/21 Kristian Rosenvold <[email protected]>: >> 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) ? > > Now it's getting interesting: > > git clone git://git.apache.org/maven-surefire.git > cd maven-surefire > gitk --all & > > git clone https://github.com/sonatype/plexus-utils.git > cd plexus-utils > gitk --all & > > > Hold the two gitk windows side by side;) > > Now the tags in surefire seem like the textbook way to do this, > whereas plexus-utils has ugly tags. But is there any way to have > release-plugin actually *make* tags like surefire has ? (these are > from the asf git clone, so they have been created by some dark > magics...)
magic maybe but not a black box as it's "open source" :-) see the svn asf git cloning stuff here https://svn.apache.org/repos/infra/infrastructure/trunk/projects/git/ > > Kristian > > > > >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Kristian Rosenvold <[email protected]> >>> To: Maven Developers List <[email protected]> >>> 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 <[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] >>> >> >> --------------------------------------------------------------------- >> 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]
