On 21 September 2012 12:58, Stephen Connolly < [email protected]> wrote:
> > > On 21 September 2012 12:40, Kristian Rosenvold < > [email protected]> wrote: > >> > 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...) >> > > I think this is a side-effect of the svn-git migration > > the plexus ones are where the tag is created on the master branch > > the surefire ones are where the tag is created from a separate branch > (i.e. the tag) > > to have the history like this in git you would do something like > > here is the way # update poms $ git commit -m "[maven-release-plugin] prepare release surefire-2.12.2" $ git checkout -b temp $ git commit --allow-empty -m "[maven-release-plugin] copy tag for surefire-2.12.2" $ git tag surefire-2.12.2 $ git checkout master # update poms $ git commit -m "[maven-release-plugin] prepare for next development iteration" > >> >> 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] >> >> >
