+1 On Tue, Jan 2, 2018 at 2:41 PM Boris Stoyanov <boris.stoya...@shapeblue.com> wrote:
> 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 > >> > >> > >> > >> > >
