You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rafael Weingärtner <ra...@gmail.com> on 2018/01/02 11:46:24 UTC
[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
Re: [VOTE] Clean up old and obsolete branches.
Posted by Rafael Weingärtner <ra...@gmail.com>.
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 <wi...@widodh.nl> wrote:
>
> > +1
> >
> > > Op 3 jan. 2018 om 09:02 heeft Rohit Yadav <ro...@shapeblue.com>
> > het volgende geschreven:
> > >
> > > +0
> > >
> > >
> > > - Rohit
> > >
> > > <https://cloudstack.apache.org>
> > >
> > >
> > >
> > > ________________________________
> > > From: Rafael Weingärtner <ra...@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.yadav@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> >
>
--
Rafael Weingärtner
Re: [VOTE] Clean up old and obsolete branches.
Posted by Marc-Aurèle Brothier <ma...@exoscale.ch>.
+1
On Wed, Jan 3, 2018 at 9:56 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> +1
>
> > Op 3 jan. 2018 om 09:02 heeft Rohit Yadav <ro...@shapeblue.com>
> het volgende geschreven:
> >
> > +0
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > ________________________________
> > From: Rafael Weingärtner <ra...@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.yadav@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
>
Re: [VOTE] Clean up old and obsolete branches.
Posted by Wido den Hollander <wi...@widodh.nl>.
+1
> Op 3 jan. 2018 om 09:02 heeft Rohit Yadav <ro...@shapeblue.com> het volgende geschreven:
>
> +0
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> ________________________________
> From: Rafael Weingärtner <ra...@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.yadav@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
Re: [VOTE] Clean up old and obsolete branches.
Posted by Rohit Yadav <ro...@shapeblue.com>.
+0
- Rohit
<https://cloudstack.apache.org>
________________________________
From: Rafael Weingärtner <ra...@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.yadav@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: [VOTE] Clean up old and obsolete branches.
Posted by ilya musayev <il...@gmail.com>.
+1
On Tue, Jan 2, 2018 at 2:41 PM Boris Stoyanov <bo...@shapeblue.com>
wrote:
> 0
>
>
> boris.stoyanov@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
> > On 2 Jan 2018, at 22:13, Khosrow Moossavi <km...@cloudops.com>
> wrote:
> >
> > +1
> >
> > Khosrow Moossavi
> > CloudOps
> >
> > On Jan 2, 2018 14:07, "Nicolas Vazquez" <Ni...@shapeblue.com>
> > wrote:
> >
> >> +1
> >>
> >> ________________________________
> >> From: Simon Weller <sw...@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 <da...@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 <
> >> gabrascher@gmail.com
> >>> wrote:
> >>
> >>> +1
> >>>
> >>> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <
> >> rafaelweingartner@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.Vazquez@shapeblue.com
> >> www.shapeblue.com
> >> ,
> >> @shapeblue
> >>
> >>
> >>
> >>
>
>
Re: [VOTE] Clean up old and obsolete branches.
Posted by Boris Stoyanov <bo...@shapeblue.com>.
0
boris.stoyanov@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
> On 2 Jan 2018, at 22:13, Khosrow Moossavi <km...@cloudops.com> wrote:
>
> +1
>
> Khosrow Moossavi
> CloudOps
>
> On Jan 2, 2018 14:07, "Nicolas Vazquez" <Ni...@shapeblue.com>
> wrote:
>
>> +1
>>
>> ________________________________
>> From: Simon Weller <sw...@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 <da...@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 <
>> gabrascher@gmail.com
>>> wrote:
>>
>>> +1
>>>
>>> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <
>> rafaelweingartner@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.Vazquez@shapeblue.com
>> www.shapeblue.com
>> ,
>> @shapeblue
>>
>>
>>
>>
Re: [VOTE] Clean up old and obsolete branches.
Posted by Khosrow Moossavi <km...@cloudops.com>.
+1
Khosrow Moossavi
CloudOps
On Jan 2, 2018 14:07, "Nicolas Vazquez" <Ni...@shapeblue.com>
wrote:
> +1
>
> ________________________________
> From: Simon Weller <sw...@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 <da...@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 <
> gabrascher@gmail.com
> > wrote:
>
> > +1
> >
> > 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <
> rafaelweingartner@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.Vazquez@shapeblue.com
> www.shapeblue.com
> ,
> @shapeblue
>
>
>
>
Re: [VOTE] Clean up old and obsolete branches.
Posted by Nicolas Vazquez <Ni...@shapeblue.com>.
+1
________________________________
From: Simon Weller <sw...@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 <da...@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 <gabrascher@gmail.com
> wrote:
> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <rafaelweingartner@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.Vazquez@shapeblue.com
www.shapeblue.com
,
@shapeblue
Re: [VOTE] Clean up old and obsolete branches.
Posted by Simon Weller <sw...@ena.com.INVALID>.
+0
________________________________
From: Daan Hoogland <da...@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 <gabrascher@gmail.com
> wrote:
> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <rafaelweingartner@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
Re: [VOTE] Clean up old and obsolete branches.
Posted by Daan Hoogland <da...@gmail.com>.
0
On Tue, Jan 2, 2018 at 1:51 PM, Gabriel Beims Bräscher <gabrascher@gmail.com
> wrote:
> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <rafaelweingartner@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
Re: [VOTE] Clean up old and obsolete branches.
Posted by Gabriel Beims Bräscher <ga...@gmail.com>.
+1
2018-01-02 9:46 GMT-02:00 Rafael Weingärtner <ra...@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
>