[VOTE] Clean up old and obsolete branches.

[Rafael Weingärtner]

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.

[Gabriel Beims Bräscher]

+1

2018-01-02 9:46 GMT-02:00 Rafael Weingärtner :

> 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.

[Daan Hoogland]

0

On Tue, Jan 2, 2018 at 1:51 PM, Gabriel Beims Bräscher  wrote:

> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner  >:
>
> > 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.

[Simon Weller]

+0


From: Daan Hoogland 
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  wrote:

> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner  >:
>
> > 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.

[Nicolas Vazquez]

+1


From: Simon Weller 
Sent: Tuesday, January 2, 2018 3:38:00 PM
To: dev
Subject: Re: [VOTE] Clean up old and obsolete branches.

+0


From: Daan Hoogland 
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  wrote:

> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner  >:
>
> > 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
  
 

Re: [VOTE] Clean up old and obsolete branches.

[Khosrow Moossavi]

+1

Khosrow Moossavi
CloudOps

On Jan 2, 2018 14:07, "Nicolas Vazquez" 
wrote:

> +1
>
> 
> From: Simon Weller 
> Sent: Tuesday, January 2, 2018 3:38:00 PM
> To: dev
> Subject: Re: [VOTE] Clean up old and obsolete branches.
>
> +0
>
> 
> From: Daan Hoogland 
> 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
>
>
>
>

Re: [VOTE] Clean up old and obsolete branches.

[Boris Stoyanov]

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  wrote:
> 
> +1
> 
> Khosrow Moossavi
> CloudOps
> 
> On Jan 2, 2018 14:07, "Nicolas Vazquez" 
> wrote:
> 
>> +1
>> 
>> 
>> From: Simon Weller 
>> Sent: Tuesday, January 2, 2018 3:38:00 PM
>> To: dev
>> Subject: Re: [VOTE] Clean up old and obsolete branches.
>> 
>> +0
>> 
>> 
>> From: Daan Hoogland 
>> 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
>> 
>> 
>> 
>> 

Re: [VOTE] Clean up old and obsolete branches.

[ilya musayev]

+1

On Tue, Jan 2, 2018 at 2:41 PM Boris Stoyanov 
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 
> wrote:
> >
> > +1
> >
> > Khosrow Moossavi
> > CloudOps
> >
> > On Jan 2, 2018 14:07, "Nicolas Vazquez" 
> > wrote:
> >
> >> +1
> >>
> >> 
> >> From: Simon Weller 
> >> Sent: Tuesday, January 2, 2018 3:38:00 PM
> >> To: dev
> >> Subject: Re: [VOTE] Clean up old and obsolete branches.
> >>
> >> +0
> >>
> >> 
> >> From: Daan Hoogland 
> >> 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
> >>
> >>
> >>
> >>
>
>

Re: [DISCUSS] Changing events to include UUIDs, could it break your integration

[Venkata Yedugundla]

Hi all,


We need to go with api versioning at some point. However, it may not be right 
to park this till we get api versioning done.  Even if we add a global 
configuration, at some point the dependent apps need to work with uuids and its 
again some more work is needed on this. Instead let the dependent apps (if 
there are not too many) plan to work with  uuid  before 4.12 (may be they can 
continue using the id based on type of data)  and we can give the heads up 
about the same in the documentation of 4.11.


Thanks,

Subhash


From: Rohit Yadav 
Sent: 01 January 2018 16:12:28
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Changing events to include UUIDs, could it break your 
integration

(not voting, but) +1 to the general idea of API versioning as a separate 
initiative.


- Rohit


[https://cloudstack.apache.org/images/monkey-144.png]

Apache CloudStack: Open Source Cloud Computing
cloudstack.apache.org
CloudStack is open source cloud computing software for creating, managing, and 
deploying infrastructure cloud services







From: Rene Moser 
Sent: Thursday, December 28, 2017 9:37:18 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Changing events to include UUIDs, could it break your 
integration

Hi

On 12/28/2017 10:52 AM, Rohit Yadav wrote:
> All,
>
>
> We've come across a pull request which changes the event description to 
> use/export UUIDs instead of the numeric internal ID of a resource. I'm not 
> sure if this could potentially break any external integration such as 
> billing, crms etc. so wanted to get your feedback on this. My understanding 
> is external billing/intergrations would consume from the usage related tables 
> for data than events table.
>
>
> The PR is https://github.com/apache/cloudstack/pull/1940
>
>
> Comments, thoughts? Thanks.

Even though I am +1 with this change, we should work towards versioning
the API to prevent breaking anything out there.

René

rohit.ya...@shapeblue.com
www.shapeblue.com
[http://www.shapeblue.com/wp-content/uploads/2017/06/logo.png]

Shapeblue - The CloudStack Company
www.shapeblue.com
Rapid deployment framework for Apache CloudStack IaaS Clouds. CSForge is a 
framework developed by ShapeBlue to deliver the rapid deployment of a 
standardised ...



53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.