Well currently I've only ever seen the release plugin create the kind of tags you prefer, Mark. So you're in luck ;)
I still don't see why your argument actually changes anything: If you're just firing off a quick rc release, you can just keep the version number on trunk unchanged (hence you'd have just one commit, being the release on a small mini-branch of its own...) Hence you 'd have NO commit on trunk to show the release... Kristian 2012/9/21 Mark Struberg <[email protected]>: > I'd rather have the 'release' commit (the one inbetween without the > -SNAPSHOT) in the history. > > Reason is that the snapshot versions might be completely different than the > others. > We have this e.g. if you have > > 1.0-SNAPSHOT > > then you release a > 1.0-rc3 > > > and continue with > > > > 1.0-SNAPSHOT > > again. > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Kristian Rosenvold <[email protected]> >> To: Maven Developers List <[email protected]> >> Cc: >> Sent: Friday, September 21, 2012 2:15 PM >> Subject: Re: Scm, Surefire, Wagon migrate to git (please check) [was Plan >> for git migration] >> >> Well the "prepare" commit is really just not needed. Viewing >> "master" >> as a linear history the commits can go directly from >> "2.12-SNAPSHOT" to "2.13-SNAPSHOT", since 2.12 can be on its >> own >> mini-branch, like the asf repos do. >> >> Now of course dropping the tag would also imply reverting the commit >> version number on trunk. But there is no way to make release-plugin >> actually do this style of tagging ? >> >> In this way if you're a lazy guy or know way too much git you can do >> as follows: >> >> tocuh poms to 2.12.2 >> git commit -m "[maven-release-plugin] copy tag for surefire-2.12.2" >> git push origin HEAD:refs/tags/surefire-2.12.2 >> touch poms to 2.13-SNAPSHOT >> git commit --amend -m"[maven-release-plugin] prepare for next >> development" >> git push origin HEAD:master >> >> Kristian >> >> >> >> >> 2012/9/21 Stephen Connolly <[email protected]>: >>> 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] >>>> >>>> >> >> --------------------------------------------------------------------- >> 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]
