> 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...) 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]
