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 git commit -m "[maven-release-plugin] prepare release surefire-2.12.2" git checkout -b temp touch the git properties to refelect the new svn revision git commit -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] > >
