Do we really want something like that??? Isn't the underlying ethos for maven/releases is that the are cheap and easy? So, just roll another release...?
-Chris Sent from my iPhone On 22/09/2012, at 3:58 AM, "Robert Scholte" <[email protected]> wrote: > So we need something like https://jira.codehaus.org/browse/MRELEASE-430 ? > > > Op Fri, 21 Sep 2012 13:41:14 +0200 schreef Arnaud Héritier > <[email protected]>: > >> I agree to not create releases from master but from a dedicated release >> branch which will be merged after the vote at the same time we release the >> staging repository >> >> Arnaud >> >> On Fri, Sep 21, 2012 at 1:22 PM, Mark Struberg <[email protected]> wrote: >> >>> Ok, we need to figure how this works together with all the auto-mirrors >>> around (github/asf/maven, etc). >>> >>> 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) ? >>> >>> 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]
