0
boris.stoya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > On 2 Jan 2018, at 22:13, Khosrow Moossavi <kmooss...@cloudops.com> wrote: > > +1 > > Khosrow Moossavi > CloudOps > > On Jan 2, 2018 14:07, "Nicolas Vazquez" <nicolas.vazq...@shapeblue.com> > wrote: > >> +1 >> >> ________________________________ >> From: Simon Weller <swel...@ena.com.INVALID> >> Sent: Tuesday, January 2, 2018 3:38:00 PM >> To: dev >> Subject: Re: [VOTE] Clean up old and obsolete branches. >> >> +0 >> >> ________________________________ >> From: Daan Hoogland <daan.hoogl...@gmail.com> >> Sent: Tuesday, January 2, 2018 12:19 PM >> To: dev >> Subject: Re: [VOTE] Clean up old and obsolete branches. >> >> 0 >> >> On Tue, Jan 2, 2018 at 1:51 PM, Gabriel Beims Bräscher < >> gabrasc...@gmail.com >>> wrote: >> >>> +1 >>> >>> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner < >> rafaelweingart...@gmail.com >>>> : >>> >>>> Hope you guys had great holy days! >>>> >>>> Resuming the discussion we started last year in [1]. It is time to vote >>> and >>>> then to push (if the vote is successful) the protocol defined to our >>> wiki. >>>> Later we can start enforcing it. >>>> I will summarize the protocol for branches in the official repository. >>>> >>>> 1. We only maintain the master and major release branches. We >>> currently >>>> have a system of X.Y.Z.S. I define major release here as a release >>> that >>>> changes either ((X or Y) or (X and Y)); >>>> 2. We will use tags for versioning. Therefore, all versions we >> release >>>> are tagged accordingly, including minor and security releases; >>>> 3. When releasing the “SNAPSHOT” is removed and the branch of the >>>> version is created (if the version is being cut from master). Rule >> (1) >>>> one >>>> is applied here; therefore, only major releases will receive >> branches. >>>> Every release must have a tag according to the format X.Y.Z.S. After >>>> releasing, we bump the POM of the version to next available >> SNAPSHOT; >>>> 4. If there's a need to fix an old version, we work on HEAD of >>>> corresponding release branch. For instance, if we want to fix >>> something >>>> in >>>> release 4.1.1.0, we will work on branch 4.1, which will have the POM >>>> set to >>>> 4.1.2.0-SNAPSHOT; >>>> 5. People should avoid (it is not forbidden though) using the >> official >>>> apache repository to store working branches. If we want to work >>>> together on >>>> some issues, we can set up a fork and give permission to interested >>>> parties >>>> (the official repository is restricted to committers). If one uses >> the >>>> official repository, the branch used must be cleaned right after >>>> merging; >>>> 6. Branches not following these rules will be removed if they have >> not >>>> received attention (commits) for over 6 (six) months; >>>> 7. Before the removal of a branch in the official repository it is >>>> mandatory to create a Jira ticket and send a notification email to >>>> CloudStack’s dev mailing list. If there are no objections, the >> branch >>>> can >>>> be deleted seven (7) business days after the notification email is >>> sent; >>>> 8. After the branch removal, the Jira ticket must be closed. >>>> >>>> Let’s go to the poll: >>>> (+1) – I want to work using this protocol >>>> (0) – Indifferent to me >>>> (-1) – I prefer the way it is not, without any protocol/guidelines >>>> >>>> >>>> [1] >>>> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/ >>>> 201711.mbox/%3CCAHGRR8ozDBX%3DJJewLz_cu-YP9vA3TEmesvxGArTDBPerAOj8Cw% >>>> 40mail.gmail.com%3E >>>> >>>> -- >>>> Rafael Weingärtner >>>> >>> >> >> >> >> -- >> Daan >> >> nicolas.vazq...@shapeblue.com >> www.shapeblue.com >> , >> @shapeblue >> >> >> >>
