I am now closing the vote. The result is the following: (+1) - 6 (0) - 4 (-1) – 0
The voting was successful. I created a page presenting the protocol in CloudStack’s wiki [1]. We can now start using it. Thanks for everybody that helped discussing and voting. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol On Wed, Jan 3, 2018 at 7:11 AM, Marc-Aurèle Brothier <ma...@exoscale.ch> wrote: > +1 > > On Wed, Jan 3, 2018 at 9:56 AM, Wido den Hollander <w...@widodh.nl> wrote: > > > +1 > > > > > Op 3 jan. 2018 om 09:02 heeft Rohit Yadav <rohit.ya...@shapeblue.com> > > het volgende geschreven: > > > > > > +0 > > > > > > > > > - Rohit > > > > > > <https://cloudstack.apache.org> > > > > > > > > > > > > ________________________________ > > > From: Rafael Weingärtner <rafaelweingart...@gmail.com> > > > Sent: Tuesday, January 2, 2018 5:16:24 PM > > > To: dev@cloudstack.apache.org > > > Subject: [VOTE] Clean up old and obsolete branches. > > > > > > 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 > > > > > > rohit.ya...@shapeblue.com > > > www.shapeblue.com > > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > @shapeblue > > > > > > > > > > > > -- Rafael Weingärtner
