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]
