:34 PM, Sudha Ponnaganti
> wrote:
>
> > Do you mean pre- release defects would retain code name and Post
> release defects would have a codename + release version??
> >
> >
> > -Original Message-
> > From: John Burwell [mailto:jburw...@basho.
ects would have a codename + release version??
>
>
> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Monday, July 15, 2013 1:17 PM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
>
> Sudha,
>
> Sorry,
model. But for
> operationally if this is easy for us to move defects I am fine with it.
>
>
> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Tuesday, July 02, 2013 7:01 AM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development R
for
> operationally if this is easy for us to move defects I am fine with it.
>
>
> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Tuesday, July 02, 2013 7:01 AM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
>
AM
To: dev@cloudstack.apache.org
Subject: Re: In-Development Release Naming
Sudha,
I think it would make tickets easier to comprehend for the casual project
contributor/follower. Additionally, the reality is that all tickets don't get
closed during the development cycle. As I think throu
rwell [mailto:jburw...@basho.com]
> Sent: Tuesday, July 02, 2013 6:27 AM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
>
> Sudha,
>
> In JIRA, is it possible to change an exist release name? If so, we use the
> code name until the relea
[mailto:jburw...@basho.com]
Sent: Tuesday, July 02, 2013 6:27 AM
To: dev@cloudstack.apache.org
Subject: Re: In-Development Release Naming
Sudha,
In JIRA, is it possible to change an exist release name? If so, we use the
code name until the release is cut, and change the JIRA release name to x.y.z
02, 2013 6:13 AM
> To: dev@cloudstack.apache.org
> Subject: Re: In-Development Release Naming
>
> Sebastien,
>
> Actually, you are completely correct. When we cut a release branch, we know
> the scope of change and can apply of the semantic versioning rules to service
>
...@basho.com]
Sent: Tuesday, July 02, 2013 6:13 AM
To: dev@cloudstack.apache.org
Subject: Re: In-Development Release Naming
Sebastien,
Actually, you are completely correct. When we cut a release branch, we know
the scope of change and can apply of the semantic versioning rules to service
the
Sebastien,
Actually, you are completely correct. When we cut a release branch, we know
the scope of change and can apply of the semantic versioning rules to service
the correct version number (i.e. whether to increment x, y, or z). However, we
have a 4 month period of development on feature r
On 7/2/13 10:22 AM, Daan Hoogland wrote:
On Tue, Jul 2, 2013 at 10:02 AM, Sebastien Goasguenwrote:
To me, codenames are confusing . I'd rather see a clear message like "we
are bumping the release number to version x.y because of this major
feature…." than start talking about a " "gammaray"
On Tue, Jul 2, 2013 at 10:02 AM, Sebastien Goasguen wrote:
> To me, codenames are confusing . I'd rather see a clear message like "we
> are bumping the release number to version x.y because of this major
> feature…." than start talking about a " "gammaray" pre-RC dev release that
> will later mayb
On Jul 2, 2013, at 1:31 AM, Daan Hoogland wrote:
> John,
>
> If I understand you, we will call master x.(y+1) with x.y being the latest
> unpatched release unless we decide that it is not going to be x-compatible
> anymore. We will publish x.(y+1) as some symbolic name, possibly reflecting
> a
John,
If I understand you, we will call master x.(y+1) with x.y being the latest
unpatched release unless we decide that it is not going to be x-compatible
anymore. We will publish x.(y+1) as some symbolic name, possibly reflecting
a running gag from the latest collab, until it is decided whether
Chip,
On Mon, Jul 1, 2013 at 4:15 PM, Chip Childers wrote:
> On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> > All,
> >
> > Since we have adopted Semantic Versioning [1], it seems odd that we
> designate a release version before the final set of enhancements/fixes has
> been iden
On Mon, Jul 01, 2013 at 10:40:38PM +0200, Daan Hoogland wrote:
> That doesn't invalidate John's point about the message to the users. We can
> publish it by a code name and still code it with numbers according to our
> expectations of the level of bump it will take.
Ah... I guess I was thinking t
That doesn't invalidate John's point about the message to the users. We can
publish it by a code name and still code it with numbers according to our
expectations of the level of bump it will take.
On Mon, Jul 1, 2013 at 10:15 PM, Chip Childers wrote:
> On Mon, Jul 01, 2013 at 02:28:37PM -0400,
On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> All,
>
> Since we have adopted Semantic Versioning [1], it seems odd that we designate
> a release version before the final set of enhancements/fixes has been
> identified. For example, the release proceeding 4.2 may contain no bac
Definitely a +1
Matt
On 7/1/13 2:28 PM, "John Burwell" wrote:
>All,
>
>Since we have adopted Semantic Versioning [1], it seems odd that we
>designate a release version before the final set of enhancements/fixes
>has been identified. For example, the release proceeding 4.2 may contain
>no bac
Exactly (+1) and 'gammarays' or '#gammarays' have my preference.
On Mon, Jul 1, 2013 at 8:28 PM, John Burwell wrote:
> All,
>
> Since we have adopted Semantic Versioning [1], it seems odd that we
> designate a release version before the final set of enhancements/fixes has
> been identified. F
20 matches
Mail list logo
