[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Vinod Kumar Vavilapalli <vi...@apache.org>]

Forking the thread to make sure it attracts enough eye-balls. The earlier one was about 3.0.0 specifically and I don’t think enough people were watching that.

I’ll try to summarize a bit.

# Today’s state of release numbering and ordering:
    So far, all the releases we have done, we have followed a simple timeline ordering. By this I mean that we always lined up releases one after another. Due to this, it was relatively simple to follow the causal ordering of releases, and we could answer ordering questions like “when was this patch first committed”.

    The first time this started getting hairy was with parallel 2.6.x and 2.7.x releases. We managed the confusion by ordering them one after another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked okay with two concurrent releases. 

    Yes, by doing this, we could no longer answer questions by simply looking at the release numbers. But Sangjin / Junping / myself who did these 2.x releases ordered them one after another to avoid further confusion to developers and still retain the ability to just go back, look at the history and quickly answer the question of "what happened before and what happened after”. It wasn’t perfect, but we did what we did to keep it under control.

# What’s coming
    Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x, 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering becomes a nightmare. The related problems that were discussed in the original thread was about how we mark fix-versions for patches, and how we generate change-logs - the answers for both of these follow the solution to the root problem of concurrent releases.

# Proposals?
    There were some discussions about semantic versioning in the thread form which I forked this one from, but it’s not clear to me how semantic versioning supports concurrent release trains.

IAC, it’s time we look at this afresh and if need be, make some new rules before we make more of these releases and make it that much harder to follow for everyone.

Thanks
+Vinod
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.

A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.

By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.

On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
>> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>>
>> I like the 3.0.0-alphaX approach primarily for simpler understanding of
>> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
>> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
>> incompatible in APIs.
>>
>> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@gmail.com
>> > > > wrote:
>> > >
>> > >> 1. I probably missed something but I didn't get it how "alpha"s made
>> > >> their way into release numbers again. This was discussed on several
>> > >> occasions and I thought the common perception was to use just three
>> > level
>> > >> numbers for release versioning and avoid branding them.
>> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
>> What
>> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk
>> to
>> > >> 3.1.0 would be perfectly in line with our current release practices.
>> > >>
>> > >
>> > > We discussed release numbering a while ago when discussing the release
>> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
>> > > fourth level as you say, but the intent is to only use it (and
>> "-betaX")
>> > in
>> > > the leadup to 3.0.0.
>> > >
>> > > The goal here is clarity for end users, since most other enterprise
>> > > software uses a a.0.0 version to denote the GA of a new major version.
>> > Same
>> > > for a.b.0 for a new minor version, though we haven't talked about that
>> > yet.
>> > > The alphaX and betaX scheme also shares similarity to release
>> versioning
>> > of
>> > > other enterprise software.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> > >> The release number is not intended to reflect historical release
>> > >> sequence, but rather the point in the source tree, which it was
>> branched
>> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>> > >>
>> > >
>> > > As described earlier in this thread, the issue here is setting the fix
>> > > versions such that the changelog is a useful diff from a previous
>> > version,
>> > > and also clear about what changes are present in each branch. If we do
>> > not
>> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
>> > from.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We
>> may
>> > >> think of another rule that if a release branch is not released in 3
>> > month
>> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
>> > too
>> > >> much work syncing it with branch-2.
>> > >>
>> > >> Time-based rules are tough here. I'd prefer we continue to leave
>> this up
>> > > to release managers. If you think we should recut branch-2.8,
>> recommend
>> > > pinging Vinod and discussing on a new thread.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut  from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.

A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.

By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.

On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
>> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>>
>> I like the 3.0.0-alphaX approach primarily for simpler understanding of
>> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
>> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
>> incompatible in APIs.
>>
>> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@gmail.com
>> > > > wrote:
>> > >
>> > >> 1. I probably missed something but I didn't get it how "alpha"s made
>> > >> their way into release numbers again. This was discussed on several
>> > >> occasions and I thought the common perception was to use just three
>> > level
>> > >> numbers for release versioning and avoid branding them.
>> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
>> What
>> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk
>> to
>> > >> 3.1.0 would be perfectly in line with our current release practices.
>> > >>
>> > >
>> > > We discussed release numbering a while ago when discussing the release
>> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
>> > > fourth level as you say, but the intent is to only use it (and
>> "-betaX")
>> > in
>> > > the leadup to 3.0.0.
>> > >
>> > > The goal here is clarity for end users, since most other enterprise
>> > > software uses a a.0.0 version to denote the GA of a new major version.
>> > Same
>> > > for a.b.0 for a new minor version, though we haven't talked about that
>> > yet.
>> > > The alphaX and betaX scheme also shares similarity to release
>> versioning
>> > of
>> > > other enterprise software.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> > >> The release number is not intended to reflect historical release
>> > >> sequence, but rather the point in the source tree, which it was
>> branched
>> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>> > >>
>> > >
>> > > As described earlier in this thread, the issue here is setting the fix
>> > > versions such that the changelog is a useful diff from a previous
>> > version,
>> > > and also clear about what changes are present in each branch. If we do
>> > not
>> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
>> > from.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We
>> may
>> > >> think of another rule that if a release branch is not released in 3
>> > month
>> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
>> > too
>> > >> much work syncing it with branch-2.
>> > >>
>> > >> Time-based rules are tough here. I'd prefer we continue to leave
>> this up
>> > > to release managers. If you think we should recut branch-2.8,
>> recommend
>> > > pinging Vinod and discussing on a new thread.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut  from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.

A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.

By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.

On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
>> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>>
>> I like the 3.0.0-alphaX approach primarily for simpler understanding of
>> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
>> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
>> incompatible in APIs.
>>
>> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@gmail.com
>> > > > wrote:
>> > >
>> > >> 1. I probably missed something but I didn't get it how "alpha"s made
>> > >> their way into release numbers again. This was discussed on several
>> > >> occasions and I thought the common perception was to use just three
>> > level
>> > >> numbers for release versioning and avoid branding them.
>> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
>> What
>> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk
>> to
>> > >> 3.1.0 would be perfectly in line with our current release practices.
>> > >>
>> > >
>> > > We discussed release numbering a while ago when discussing the release
>> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
>> > > fourth level as you say, but the intent is to only use it (and
>> "-betaX")
>> > in
>> > > the leadup to 3.0.0.
>> > >
>> > > The goal here is clarity for end users, since most other enterprise
>> > > software uses a a.0.0 version to denote the GA of a new major version.
>> > Same
>> > > for a.b.0 for a new minor version, though we haven't talked about that
>> > yet.
>> > > The alphaX and betaX scheme also shares similarity to release
>> versioning
>> > of
>> > > other enterprise software.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> > >> The release number is not intended to reflect historical release
>> > >> sequence, but rather the point in the source tree, which it was
>> branched
>> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>> > >>
>> > >
>> > > As described earlier in this thread, the issue here is setting the fix
>> > > versions such that the changelog is a useful diff from a previous
>> > version,
>> > > and also clear about what changes are present in each branch. If we do
>> > not
>> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
>> > from.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We
>> may
>> > >> think of another rule that if a release branch is not released in 3
>> > month
>> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
>> > too
>> > >> much work syncing it with branch-2.
>> > >>
>> > >> Time-based rules are tough here. I'd prefer we continue to leave
>> this up
>> > > to release managers. If you think we should recut branch-2.8,
>> recommend
>> > > pinging Vinod and discussing on a new thread.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut  from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Another reason I like the 3.0.0-alphaX approach is the ease of
communicating compatibility guarantees.

A lot of our compatibility guarantees (e.g. API/wire compat) mention
"within a major release". For the user, thinking of 3.0.0 as the beginning
of a major release seems easier than 3.2.0 being the beginning. Most users
likely will not be interested in the alphas or betas; I assume downstream
projects and early adopters are the primary targets for these pre-GA
releases.

By capturing what we mean by alpha and beta, we can communicate the
compatibility guarantees moving from alpha1 to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.

On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla <ka...@cloudera.com> wrote:

> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. While being used by
> other software does not make an approach right, I think we should adopt an
> approach that is easy for our users to understand.
>
> The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
> proposed and okay for a long while. Do people still consider it okay? Is
> there a specific need to consider alternatives?
>
> On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:
>
>> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
>> something less confusing than incompatible between 2.8/2.9 and 2.98.x
>> alphas/2.99.x betas.
>> Why not just follow our previous practice in the beginning of branch-2?
>> we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing
>> our APIs, we should bump up trunk version to 4.x for landing new
>> incompatible changes.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Karthik Kambatla <ka...@cloudera.com>
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
>> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>>
>> I like the 3.0.0-alphaX approach primarily for simpler understanding of
>> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
>> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
>> incompatible in APIs.
>>
>> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
>> to a 3.0.0 GA. I have seen other projects use this without causing much
>> confusion.
>>
>> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <shv.hadoop@gmail.com
>> >
>> wrote:
>>
>> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
>> > wrote:
>> >
>> > > Hi Konst, thanks for commenting,
>> > >
>> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
>> > shv.hadoop@gmail.com
>> > > > wrote:
>> > >
>> > >> 1. I probably missed something but I didn't get it how "alpha"s made
>> > >> their way into release numbers again. This was discussed on several
>> > >> occasions and I thought the common perception was to use just three
>> > level
>> > >> numbers for release versioning and avoid branding them.
>> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
>> What
>> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk
>> to
>> > >> 3.1.0 would be perfectly in line with our current release practices.
>> > >>
>> > >
>> > > We discussed release numbering a while ago when discussing the release
>> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
>> > > fourth level as you say, but the intent is to only use it (and
>> "-betaX")
>> > in
>> > > the leadup to 3.0.0.
>> > >
>> > > The goal here is clarity for end users, since most other enterprise
>> > > software uses a a.0.0 version to denote the GA of a new major version.
>> > Same
>> > > for a.b.0 for a new minor version, though we haven't talked about that
>> > yet.
>> > > The alphaX and betaX scheme also shares similarity to release
>> versioning
>> > of
>> > > other enterprise software.
>> > >
>> >
>> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't
>> think it
>> > went well with user perception.
>> > Say release 2.0.5-alpha turned out to be quite good even though still
>> > branded "alpha", while 2.2 was not and not branded.
>> > We should move a release to stable, when people ran it and agree it is
>> GA
>> > worthy. Otherwise you never know.
>> >
>> >
>> > >
>> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> > >> The release number is not intended to reflect historical release
>> > >> sequence, but rather the point in the source tree, which it was
>> branched
>> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>> > >>
>> > >
>> > > As described earlier in this thread, the issue here is setting the fix
>> > > versions such that the changelog is a useful diff from a previous
>> > version,
>> > > and also clear about what changes are present in each branch. If we do
>> > not
>> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
>> > from.
>> > >
>> >
>> > So the problem is in determining the latest commit, which was not
>> present
>> > in the last release, when the last release bears higher number than the
>> one
>> > being released.
>> > Interesting problem. Don't have a strong opinion on that. I guess it's
>> OK
>> > to have overlapping in changelogs.
>> > As long as we keep following the rule that commits should be made to
>> trunk
>> > first and them propagated to lower branches until the target branch is
>> > reached.
>> >
>> >
>> > >
>> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We
>> may
>> > >> think of another rule that if a release branch is not released in 3
>> > month
>> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
>> > too
>> > >> much work syncing it with branch-2.
>> > >>
>> > >> Time-based rules are tough here. I'd prefer we continue to leave
>> this up
>> > > to release managers. If you think we should recut branch-2.8,
>> recommend
>> > > pinging Vinod and discussing on a new thread.
>> > >
>> >
>> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to
>> RM)
>> > can recut  from the desired point.
>> > People were committing to branch-2 and branch-2.8 for months. And they
>> are
>> > out of sync anyways. So what's the point of the extra commit.
>> > Probably still a different thread.
>> >
>> > Thanks,
>> > --Konst
>> >
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.

The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?

On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:

> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>
> I like the 3.0.0-alphaX approach primarily for simpler understanding of
> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
> incompatible in APIs.
>
> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@gmail.com
> > > > wrote:
> > >
> > >> 1. I probably missed something but I didn't get it how "alpha"s made
> > >> their way into release numbers again. This was discussed on several
> > >> occasions and I thought the common perception was to use just three
> > level
> > >> numbers for release versioning and avoid branding them.
> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
> What
> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> > >> 3.1.0 would be perfectly in line with our current release practices.
> > >>
> > >
> > > We discussed release numbering a while ago when discussing the release
> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > > fourth level as you say, but the intent is to only use it (and
> "-betaX")
> > in
> > > the leadup to 3.0.0.
> > >
> > > The goal here is clarity for end users, since most other enterprise
> > > software uses a a.0.0 version to denote the GA of a new major version.
> > Same
> > > for a.b.0 for a new minor version, though we haven't talked about that
> > yet.
> > > The alphaX and betaX scheme also shares similarity to release
> versioning
> > of
> > > other enterprise software.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> > >> The release number is not intended to reflect historical release
> > >> sequence, but rather the point in the source tree, which it was
> branched
> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> > >>
> > >
> > > As described earlier in this thread, the issue here is setting the fix
> > > versions such that the changelog is a useful diff from a previous
> > version,
> > > and also clear about what changes are present in each branch. If we do
> > not
> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> > from.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> > >> think of another rule that if a release branch is not released in 3
> > month
> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> > too
> > >> much work syncing it with branch-2.
> > >>
> > >> Time-based rules are tough here. I'd prefer we continue to leave this
> up
> > > to release managers. If you think we should recut branch-2.8, recommend
> > > pinging Vinod and discussing on a new thread.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut  from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.

The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?

On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:

> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>
> I like the 3.0.0-alphaX approach primarily for simpler understanding of
> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
> incompatible in APIs.
>
> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@gmail.com
> > > > wrote:
> > >
> > >> 1. I probably missed something but I didn't get it how "alpha"s made
> > >> their way into release numbers again. This was discussed on several
> > >> occasions and I thought the common perception was to use just three
> > level
> > >> numbers for release versioning and avoid branding them.
> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
> What
> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> > >> 3.1.0 would be perfectly in line with our current release practices.
> > >>
> > >
> > > We discussed release numbering a while ago when discussing the release
> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > > fourth level as you say, but the intent is to only use it (and
> "-betaX")
> > in
> > > the leadup to 3.0.0.
> > >
> > > The goal here is clarity for end users, since most other enterprise
> > > software uses a a.0.0 version to denote the GA of a new major version.
> > Same
> > > for a.b.0 for a new minor version, though we haven't talked about that
> > yet.
> > > The alphaX and betaX scheme also shares similarity to release
> versioning
> > of
> > > other enterprise software.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> > >> The release number is not intended to reflect historical release
> > >> sequence, but rather the point in the source tree, which it was
> branched
> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> > >>
> > >
> > > As described earlier in this thread, the issue here is setting the fix
> > > versions such that the changelog is a useful diff from a previous
> > version,
> > > and also clear about what changes are present in each branch. If we do
> > not
> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> > from.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> > >> think of another rule that if a release branch is not released in 3
> > month
> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> > too
> > >> much work syncing it with branch-2.
> > >>
> > >> Time-based rules are tough here. I'd prefer we continue to leave this
> up
> > > to release managers. If you think we should recut branch-2.8, recommend
> > > pinging Vinod and discussing on a new thread.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut  from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.

The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?

On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:

> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>
> I like the 3.0.0-alphaX approach primarily for simpler understanding of
> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
> incompatible in APIs.
>
> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@gmail.com
> > > > wrote:
> > >
> > >> 1. I probably missed something but I didn't get it how "alpha"s made
> > >> their way into release numbers again. This was discussed on several
> > >> occasions and I thought the common perception was to use just three
> > level
> > >> numbers for release versioning and avoid branding them.
> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
> What
> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> > >> 3.1.0 would be perfectly in line with our current release practices.
> > >>
> > >
> > > We discussed release numbering a while ago when discussing the release
> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > > fourth level as you say, but the intent is to only use it (and
> "-betaX")
> > in
> > > the leadup to 3.0.0.
> > >
> > > The goal here is clarity for end users, since most other enterprise
> > > software uses a a.0.0 version to denote the GA of a new major version.
> > Same
> > > for a.b.0 for a new minor version, though we haven't talked about that
> > yet.
> > > The alphaX and betaX scheme also shares similarity to release
> versioning
> > of
> > > other enterprise software.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> > >> The release number is not intended to reflect historical release
> > >> sequence, but rather the point in the source tree, which it was
> branched
> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> > >>
> > >
> > > As described earlier in this thread, the issue here is setting the fix
> > > versions such that the changelog is a useful diff from a previous
> > version,
> > > and also clear about what changes are present in each branch. If we do
> > not
> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> > from.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> > >> think of another rule that if a release branch is not released in 3
> > month
> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> > too
> > >> much work syncing it with branch-2.
> > >>
> > >> Time-based rules are tough here. I'd prefer we continue to leave this
> up
> > > to release managers. If you think we should recut branch-2.8, recommend
> > > pinging Vinod and discussing on a new thread.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut  from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I am
not aware of any other software shipped that way. While being used by other
software does not make an approach right, I think we should adopt an
approach that is easy for our users to understand.

The notion of 3.0.0-alphaX and 3.0.0-betaX ending in 3.0.0 (GA) has been
proposed and okay for a long while. Do people still consider it okay? Is
there a specific need to consider alternatives?

On Mon, Aug 8, 2016 at 11:44 AM, Junping Du <jd...@hortonworks.com> wrote:

> I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is
> something less confusing than incompatible between 2.8/2.9 and 2.98.x
> alphas/2.99.x betas.
> Why not just follow our previous practice in the beginning of branch-2? we
> can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our
> APIs, we should bump up trunk version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Karthik Kambatla <ka...@cloudera.com>
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2)
> releases [Was Setting JIRA fix versions for 3.0.0 releases]
>
> I like the 3.0.0-alphaX approach primarily for simpler understanding of
> compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
> because, it is not immediately clear that 3.0.0 and 3.1.0 could be
> incompatible in APIs.
>
> I am open to something like 2.98.x for alphas and 2.99.x for betas leading
> to a 3.0.0 GA. I have seen other projects use this without causing much
> confusion.
>
> On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
> > On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> > wrote:
> >
> > > Hi Konst, thanks for commenting,
> > >
> > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> > shv.hadoop@gmail.com
> > > > wrote:
> > >
> > >> 1. I probably missed something but I didn't get it how "alpha"s made
> > >> their way into release numbers again. This was discussed on several
> > >> occasions and I thought the common perception was to use just three
> > level
> > >> numbers for release versioning and avoid branding them.
> > >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2.
> What
> > >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> > >> 3.1.0 would be perfectly in line with our current release practices.
> > >>
> > >
> > > We discussed release numbering a while ago when discussing the release
> > > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > > fourth level as you say, but the intent is to only use it (and
> "-betaX")
> > in
> > > the leadup to 3.0.0.
> > >
> > > The goal here is clarity for end users, since most other enterprise
> > > software uses a a.0.0 version to denote the GA of a new major version.
> > Same
> > > for a.b.0 for a new minor version, though we haven't talked about that
> > yet.
> > > The alphaX and betaX scheme also shares similarity to release
> versioning
> > of
> > > other enterprise software.
> > >
> >
> > As you remember we did this (alpha, beta) for Hadoop-2 and I don't think
> it
> > went well with user perception.
> > Say release 2.0.5-alpha turned out to be quite good even though still
> > branded "alpha", while 2.2 was not and not branded.
> > We should move a release to stable, when people ran it and agree it is GA
> > worthy. Otherwise you never know.
> >
> >
> > >
> > >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> > >> The release number is not intended to reflect historical release
> > >> sequence, but rather the point in the source tree, which it was
> branched
> > >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> > >>
> > >
> > > As described earlier in this thread, the issue here is setting the fix
> > > versions such that the changelog is a useful diff from a previous
> > version,
> > > and also clear about what changes are present in each branch. If we do
> > not
> > > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> > from.
> > >
> >
> > So the problem is in determining the latest commit, which was not present
> > in the last release, when the last release bears higher number than the
> one
> > being released.
> > Interesting problem. Don't have a strong opinion on that. I guess it's OK
> > to have overlapping in changelogs.
> > As long as we keep following the rule that commits should be made to
> trunk
> > first and them propagated to lower branches until the target branch is
> > reached.
> >
> >
> > >
> > >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> > >> think of another rule that if a release branch is not released in 3
> > month
> > >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> > too
> > >> much work syncing it with branch-2.
> > >>
> > >> Time-based rules are tough here. I'd prefer we continue to leave this
> up
> > > to release managers. If you think we should recut branch-2.8, recommend
> > > pinging Vinod and discussing on a new thread.
> > >
> >
> > Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> > can recut  from the desired point.
> > People were committing to branch-2 and branch-2.8 for months. And they
> are
> > out of sync anyways. So what's the point of the extra commit.
> > Probably still a different thread.
> >
> > Thanks,
> > --Konst
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Junping Du <jd...@hortonworks.com>]

I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.

Thanks,

Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Junping Du <jd...@hortonworks.com>]

I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.

Thanks,

Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Junping Du <jd...@hortonworks.com>]

I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.

Thanks,

Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Junping Du <jd...@hortonworks.com>]

I think that incompatible API between 3.0.0-alpha and 3.1.0-beta is something less confusing than incompatible between 2.8/2.9 and 2.98.x alphas/2.99.x betas.
Why not just follow our previous practice in the beginning of branch-2? we can have 3.0.0-alpha, 3.1.0-alpha/beta, but once when we are finalizing our APIs, we should bump up trunk version to 4.x for landing new incompatible changes.

Thanks,

Junping
________________________________________
From: Karthik Kambatla <ka...@cloudera.com>
Sent: Monday, August 08, 2016 6:54 PM
Cc: common-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.

I am open to something like 2.98.x for alphas and 2.99.x for betas leading
to a 3.0.0 GA. I have seen other projects use this without causing much
confusion.

On Thu, Aug 4, 2016 at 6:01 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
> wrote:
>
> > Hi Konst, thanks for commenting,
> >
> > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <
> shv.hadoop@gmail.com
> > > wrote:
> >
> >> 1. I probably missed something but I didn't get it how "alpha"s made
> >> their way into release numbers again. This was discussed on several
> >> occasions and I thought the common perception was to use just three
> level
> >> numbers for release versioning and avoid branding them.
> >> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> >> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> >> 3.1.0 would be perfectly in line with our current release practices.
> >>
> >
> > We discussed release numbering a while ago when discussing the release
> > plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> > fourth level as you say, but the intent is to only use it (and "-betaX")
> in
> > the leadup to 3.0.0.
> >
> > The goal here is clarity for end users, since most other enterprise
> > software uses a a.0.0 version to denote the GA of a new major version.
> Same
> > for a.b.0 for a new minor version, though we haven't talked about that
> yet.
> > The alphaX and betaX scheme also shares similarity to release versioning
> of
> > other enterprise software.
> >
>
> As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
> went well with user perception.
> Say release 2.0.5-alpha turned out to be quite good even though still
> branded "alpha", while 2.2 was not and not branded.
> We should move a release to stable, when people ran it and agree it is GA
> worthy. Otherwise you never know.
>
>
> >
> >> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> >> The release number is not intended to reflect historical release
> >> sequence, but rather the point in the source tree, which it was branched
> >> off. So one can release 2.8, 2.9, etc. after or before 3.0.
> >>
> >
> > As described earlier in this thread, the issue here is setting the fix
> > versions such that the changelog is a useful diff from a previous
> version,
> > and also clear about what changes are present in each branch. If we do
> not
> > order a specific 2.x before 3.0, then we don't know what 2.x to diff
> from.
> >
>
> So the problem is in determining the latest commit, which was not present
> in the last release, when the last release bears higher number than the one
> being released.
> Interesting problem. Don't have a strong opinion on that. I guess it's OK
> to have overlapping in changelogs.
> As long as we keep following the rule that commits should be made to trunk
> first and them propagated to lower branches until the target branch is
> reached.
>
>
> >
> >> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> >> think of another rule that if a release branch is not released in 3
> month
> >> it should be abandoned. Which is applicable to branch 2.8.0 and it is
> too
> >> much work syncing it with branch-2.
> >>
> >> Time-based rules are tough here. I'd prefer we continue to leave this up
> > to release managers. If you think we should recut branch-2.8, recommend
> > pinging Vinod and discussing on a new thread.
> >
>
> Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
> can recut  from the desired point.
> People were committing to branch-2 and branch-2.8 for months. And they are
> out of sync anyways. So what's the point of the extra commit.
> Probably still a different thread.
>
> Thanks,
> --Konst
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:

> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@gmail.com
> > wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made
>> their way into release numbers again. This was discussed on several
>> occasions and I thought the common perception was to use just three level
>> numbers for release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release
> plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> fourth level as you say, but the intent is to only use it (and "-betaX") in
> the leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>

As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.


>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release
>> sequence, but rather the point in the source tree, which it was branched
>> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>

So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.


>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>

Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut  from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.

Thanks,
--Konst

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:

> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@gmail.com
> > wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made
>> their way into release numbers again. This was discussed on several
>> occasions and I thought the common perception was to use just three level
>> numbers for release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release
> plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> fourth level as you say, but the intent is to only use it (and "-betaX") in
> the leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>

As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.


>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release
>> sequence, but rather the point in the source tree, which it was branched
>> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>

So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.


>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>

Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut  from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.

Thanks,
--Konst

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

> I'm certainly open to alternate proposals for versioning and fix versions,
> but to reiterate, I like this versioning since it imitates other enterprise
> software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
> 3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.

Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.

Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>

Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.

> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.

We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

> I'm certainly open to alternate proposals for versioning and fix versions,
> but to reiterate, I like this versioning since it imitates other enterprise
> software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
> 3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.

Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.

Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>

Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.

> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.

We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

> I'm certainly open to alternate proposals for versioning and fix versions,
> but to reiterate, I like this versioning since it imitates other enterprise
> software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
> 3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.

Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.

Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>

Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.

> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.

We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

> I'm certainly open to alternate proposals for versioning and fix versions,
> but to reiterate, I like this versioning since it imitates other enterprise
> software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
> 3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
> met people who were confused by the 2.0/2.1/2.2 progression. As far as I
> know, we were unique in using this style of versioning.

Yes, but even after a stable release, we haven't blocked new (or
incompatible) features in minor releases. Some minor releases- 0.16,
0.21, 2.6.0- included complicated features that took awhile to
stabilize. Most of our x.y.0 releases are not stable, because
downstream reports come back only after we cut a release. Signaling
stability is useful, but this identifier is not reliable. At least,
it's less reliable than a section on the website recommending the
latest stable release beside alpha/beta versions.

Anyway- if we do use this, then we can use Maven's schema:
<major>.<minor>.<patch>-<identifier>-<build number>

Though I hope we won't need it, starting with 3.0.0-alpha-01 will
avoid -alpha10 as preceding -alpha2. We've discussed it enough; I'll
let it go.

> I also think what we're doing now *is* considered releasing from trunk.
> Maybe I'm missing something, but we can't literally release from trunk
> without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
> until the release or change fix versions afterwards.

We're not constrained on where we cut releases. If subsequent releases
will be off of trunk- not the -alpha branch- and we aren't
removing/holding any change until stabilizing at -beta, then we don't
need to maintain a separate release branch concurrent with development
on trunk. Bumping the release version, etc. might be useful, but a
living branch just mixes up the lineage and adds steps to commit
(trunk > 3.0.0-alpha > branch-2 > branch-2.8 > ...). If it's easier
for you to create the RC then OK. -C

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> wrote:

> I agree with Konst. The virtues of branching (instead of releasing
> from trunk) and using the version suffix for the 3.x releases are lost
> on me. Both introduce opportunities for error, in commits, in
> consistent JIRA tagging, in packaging...
>
> I'm certainly open to alternate proposals for versioning and fix versions,
but to reiterate, I like this versioning since it imitates other enterprise
software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.

I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> wrote:

> I agree with Konst. The virtues of branching (instead of releasing
> from trunk) and using the version suffix for the 3.x releases are lost
> on me. Both introduce opportunities for error, in commits, in
> consistent JIRA tagging, in packaging...
>
> I'm certainly open to alternate proposals for versioning and fix versions,
but to reiterate, I like this versioning since it imitates other enterprise
software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.

I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> wrote:

> I agree with Konst. The virtues of branching (instead of releasing
> from trunk) and using the version suffix for the 3.x releases are lost
> on me. Both introduce opportunities for error, in commits, in
> consistent JIRA tagging, in packaging...
>
> I'm certainly open to alternate proposals for versioning and fix versions,
but to reiterate, I like this versioning since it imitates other enterprise
software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.

I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas <cd...@apache.org> wrote:

> I agree with Konst. The virtues of branching (instead of releasing
> from trunk) and using the version suffix for the 3.x releases are lost
> on me. Both introduce opportunities for error, in commits, in
> consistent JIRA tagging, in packaging...
>
> I'm certainly open to alternate proposals for versioning and fix versions,
but to reiterate, I like this versioning since it imitates other enterprise
software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like
3.0.0-alpha1 will be immediately familiar to end users. Conversely, I've
met people who were confused by the 2.0/2.1/2.2 progression. As far as I
know, we were unique in using this style of versioning.

I also think what we're doing now *is* considered releasing from trunk.
Maybe I'm missing something, but we can't literally release from trunk
without a release branch (e.g. branch-3.0.0-alpha1) unless we hold commits
until the release or change fix versions afterwards.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

I agree with Konst. The virtues of branching (instead of releasing
from trunk) and using the version suffix for the 3.x releases are lost
on me. Both introduce opportunities for error, in commits, in
consistent JIRA tagging, in packaging...

We can mark stability on the website. If someone builds a cluster
without doing this basic research, marking stability in the version
number saves them from the least of the problems they'll have. This
adds complexity for clarity that's redundant, at best. -C


On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made their
>> way into release numbers again. This was discussed on several occasions and
>> I thought the common perception was to use just three level numbers for
>> release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release plan
> for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
> level as you say, but the intent is to only use it (and "-betaX") in the
> leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>
>>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release sequence,
>> but rather the point in the source tree, which it was branched off. So one
>> can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>
>>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>
> Best,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:

> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@gmail.com
> > wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made
>> their way into release numbers again. This was discussed on several
>> occasions and I thought the common perception was to use just three level
>> numbers for release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release
> plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> fourth level as you say, but the intent is to only use it (and "-betaX") in
> the leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>

As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.


>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release
>> sequence, but rather the point in the source tree, which it was branched
>> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>

So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.


>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>

Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut  from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.

Thanks,
--Konst

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com>
wrote:

> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <shv.hadoop@gmail.com
> > wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made
>> their way into release numbers again. This was discussed on several
>> occasions and I thought the common perception was to use just three level
>> numbers for release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release
> plan for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a
> fourth level as you say, but the intent is to only use it (and "-betaX") in
> the leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>

As you remember we did this (alpha, beta) for Hadoop-2 and I don't think it
went well with user perception.
Say release 2.0.5-alpha turned out to be quite good even though still
branded "alpha", while 2.2 was not and not branded.
We should move a release to stable, when people ran it and agree it is GA
worthy. Otherwise you never know.


>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release
>> sequence, but rather the point in the source tree, which it was branched
>> off. So one can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>

So the problem is in determining the latest commit, which was not present
in the last release, when the last release bears higher number than the one
being released.
Interesting problem. Don't have a strong opinion on that. I guess it's OK
to have overlapping in changelogs.
As long as we keep following the rule that commits should be made to trunk
first and them propagated to lower branches until the target branch is
reached.


>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>

Not recut, but abandon 2.8.0. And Vinod (or anybody who volunteers to RM)
can recut  from the desired point.
People were committing to branch-2 and branch-2.8 for months. And they are
out of sync anyways. So what's the point of the extra commit.
Probably still a different thread.

Thanks,
--Konst

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

I agree with Konst. The virtues of branching (instead of releasing
from trunk) and using the version suffix for the 3.x releases are lost
on me. Both introduce opportunities for error, in commits, in
consistent JIRA tagging, in packaging...

We can mark stability on the website. If someone builds a cluster
without doing this basic research, marking stability in the version
number saves them from the least of the problems they'll have. This
adds complexity for clarity that's redundant, at best. -C


On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made their
>> way into release numbers again. This was discussed on several occasions and
>> I thought the common perception was to use just three level numbers for
>> release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release plan
> for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
> level as you say, but the intent is to only use it (and "-betaX") in the
> leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>
>>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release sequence,
>> but rather the point in the source tree, which it was branched off. So one
>> can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>
>>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>
> Best,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

I agree with Konst. The virtues of branching (instead of releasing
from trunk) and using the version suffix for the 3.x releases are lost
on me. Both introduce opportunities for error, in commits, in
consistent JIRA tagging, in packaging...

We can mark stability on the website. If someone builds a cluster
without doing this basic research, marking stability in the version
number saves them from the least of the problems they'll have. This
adds complexity for clarity that's redundant, at best. -C


On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made their
>> way into release numbers again. This was discussed on several occasions and
>> I thought the common perception was to use just three level numbers for
>> release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release plan
> for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
> level as you say, but the intent is to only use it (and "-betaX") in the
> leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>
>>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release sequence,
>> but rather the point in the source tree, which it was branched off. So one
>> can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>
>>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>
> Best,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Chris Douglas <cd...@apache.org>]

I agree with Konst. The virtues of branching (instead of releasing
from trunk) and using the version suffix for the 3.x releases are lost
on me. Both introduce opportunities for error, in commits, in
consistent JIRA tagging, in packaging...

We can mark stability on the website. If someone builds a cluster
without doing this basic research, marking stability in the version
number saves them from the least of the problems they'll have. This
adds complexity for clarity that's redundant, at best. -C


On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang <an...@cloudera.com> wrote:
> Hi Konst, thanks for commenting,
>
> On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
> wrote:
>
>> 1. I probably missed something but I didn't get it how "alpha"s made their
>> way into release numbers again. This was discussed on several occasions and
>> I thought the common perception was to use just three level numbers for
>> release versioning and avoid branding them.
>> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
>> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
>> 3.1.0 would be perfectly in line with our current release practices.
>>
>
> We discussed release numbering a while ago when discussing the release plan
> for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
> level as you say, but the intent is to only use it (and "-betaX") in the
> leadup to 3.0.0.
>
> The goal here is clarity for end users, since most other enterprise
> software uses a a.0.0 version to denote the GA of a new major version. Same
> for a.b.0 for a new minor version, though we haven't talked about that yet.
> The alphaX and betaX scheme also shares similarity to release versioning of
> other enterprise software.
>
>>
>> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
>> The release number is not intended to reflect historical release sequence,
>> but rather the point in the source tree, which it was branched off. So one
>> can release 2.8, 2.9, etc. after or before 3.0.
>>
>
> As described earlier in this thread, the issue here is setting the fix
> versions such that the changelog is a useful diff from a previous version,
> and also clear about what changes are present in each branch. If we do not
> order a specific 2.x before 3.0, then we don't know what 2.x to diff from.
>
>>
>> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
>> think of another rule that if a release branch is not released in 3 month
>> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
>> much work syncing it with branch-2.
>>
>> Time-based rules are tough here. I'd prefer we continue to leave this up
> to release managers. If you think we should recut branch-2.8, recommend
> pinging Vinod and discussing on a new thread.
>
> Best,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Konst, thanks for commenting,

On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> 1. I probably missed something but I didn't get it how "alpha"s made their
> way into release numbers again. This was discussed on several occasions and
> I thought the common perception was to use just three level numbers for
> release versioning and avoid branding them.
> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> 3.1.0 would be perfectly in line with our current release practices.
>

We discussed release numbering a while ago when discussing the release plan
for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
level as you say, but the intent is to only use it (and "-betaX") in the
leadup to 3.0.0.

The goal here is clarity for end users, since most other enterprise
software uses a a.0.0 version to denote the GA of a new major version. Same
for a.b.0 for a new minor version, though we haven't talked about that yet.
The alphaX and betaX scheme also shares similarity to release versioning of
other enterprise software.

>
> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> The release number is not intended to reflect historical release sequence,
> but rather the point in the source tree, which it was branched off. So one
> can release 2.8, 2.9, etc. after or before 3.0.
>

As described earlier in this thread, the issue here is setting the fix
versions such that the changelog is a useful diff from a previous version,
and also clear about what changes are present in each branch. If we do not
order a specific 2.x before 3.0, then we don't know what 2.x to diff from.

>
> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> think of another rule that if a release branch is not released in 3 month
> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
> much work syncing it with branch-2.
>
> Time-based rules are tough here. I'd prefer we continue to leave this up
to release managers. If you think we should recut branch-2.8, recommend
pinging Vinod and discussing on a new thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Konst, thanks for commenting,

On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> 1. I probably missed something but I didn't get it how "alpha"s made their
> way into release numbers again. This was discussed on several occasions and
> I thought the common perception was to use just three level numbers for
> release versioning and avoid branding them.
> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> 3.1.0 would be perfectly in line with our current release practices.
>

We discussed release numbering a while ago when discussing the release plan
for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
level as you say, but the intent is to only use it (and "-betaX") in the
leadup to 3.0.0.

The goal here is clarity for end users, since most other enterprise
software uses a a.0.0 version to denote the GA of a new major version. Same
for a.b.0 for a new minor version, though we haven't talked about that yet.
The alphaX and betaX scheme also shares similarity to release versioning of
other enterprise software.

>
> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> The release number is not intended to reflect historical release sequence,
> but rather the point in the source tree, which it was branched off. So one
> can release 2.8, 2.9, etc. after or before 3.0.
>

As described earlier in this thread, the issue here is setting the fix
versions such that the changelog is a useful diff from a previous version,
and also clear about what changes are present in each branch. If we do not
order a specific 2.x before 3.0, then we don't know what 2.x to diff from.

>
> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> think of another rule that if a release branch is not released in 3 month
> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
> much work syncing it with branch-2.
>
> Time-based rules are tough here. I'd prefer we continue to leave this up
to release managers. If you think we should recut branch-2.8, recommend
pinging Vinod and discussing on a new thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Konst, thanks for commenting,

On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> 1. I probably missed something but I didn't get it how "alpha"s made their
> way into release numbers again. This was discussed on several occasions and
> I thought the common perception was to use just three level numbers for
> release versioning and avoid branding them.
> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> 3.1.0 would be perfectly in line with our current release practices.
>

We discussed release numbering a while ago when discussing the release plan
for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
level as you say, but the intent is to only use it (and "-betaX") in the
leadup to 3.0.0.

The goal here is clarity for end users, since most other enterprise
software uses a a.0.0 version to denote the GA of a new major version. Same
for a.b.0 for a new minor version, though we haven't talked about that yet.
The alphaX and betaX scheme also shares similarity to release versioning of
other enterprise software.

>
> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> The release number is not intended to reflect historical release sequence,
> but rather the point in the source tree, which it was branched off. So one
> can release 2.8, 2.9, etc. after or before 3.0.
>

As described earlier in this thread, the issue here is setting the fix
versions such that the changelog is a useful diff from a previous version,
and also clear about what changes are present in each branch. If we do not
order a specific 2.x before 3.0, then we don't know what 2.x to diff from.

>
> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> think of another rule that if a release branch is not released in 3 month
> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
> much work syncing it with branch-2.
>
> Time-based rules are tough here. I'd prefer we continue to leave this up
to release managers. If you think we should recut branch-2.8, recommend
pinging Vinod and discussing on a new thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Konst, thanks for commenting,

On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko <sh...@gmail.com>
wrote:

> 1. I probably missed something but I didn't get it how "alpha"s made their
> way into release numbers again. This was discussed on several occasions and
> I thought the common perception was to use just three level numbers for
> release versioning and avoid branding them.
> It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What
> is alphaX - fourth level? I think releasing 3.0.0 and setting trunk to
> 3.1.0 would be perfectly in line with our current release practices.
>

We discussed release numbering a while ago when discussing the release plan
for 3.0.0, and agreed on this scheme. "-alphaX" is essentially a fourth
level as you say, but the intent is to only use it (and "-betaX") in the
leadup to 3.0.0.

The goal here is clarity for end users, since most other enterprise
software uses a a.0.0 version to denote the GA of a new major version. Same
for a.b.0 for a new minor version, though we haven't talked about that yet.
The alphaX and betaX scheme also shares similarity to release versioning of
other enterprise software.

>
> 2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
> The release number is not intended to reflect historical release sequence,
> but rather the point in the source tree, which it was branched off. So one
> can release 2.8, 2.9, etc. after or before 3.0.
>

As described earlier in this thread, the issue here is setting the fix
versions such that the changelog is a useful diff from a previous version,
and also clear about what changes are present in each branch. If we do not
order a specific 2.x before 3.0, then we don't know what 2.x to diff from.

>
> 3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
> think of another rule that if a release branch is not released in 3 month
> it should be abandoned. Which is applicable to branch 2.8.0 and it is too
> much work syncing it with branch-2.
>
> Time-based rules are tough here. I'd prefer we continue to leave this up
to release managers. If you think we should recut branch-2.8, recommend
pinging Vinod and discussing on a new thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

1. I probably missed something but I didn't get it how "alpha"s made their
way into release numbers again. This was discussed on several occasions and
I thought the common perception was to use just three level numbers for
release versioning and avoid branding them.
It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What is
alphaX - fourth level? I think releasing 3.0.0 and setting trunk to 3.1.0
would be perfectly in line with our current release practices.

2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
The release number is not intended to reflect historical release sequence,
but rather the point in the source tree, which it was branched off. So one
can release 2.8, 2.9, etc. after or before 3.0.

3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
think of another rule that if a release branch is not released in 3 month
it should be abandoned. Which is applicable to branch 2.8.0 and it is too
much work syncing it with branch-2.

Thanks,
--Konstantin

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
>> a.b.c versions, with alpha1 being the a.b.0 release.
>>
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.

The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.

>
>> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
>> branch-2,
>> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
>> 2.7.3,
>> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
>> rule 1, and the last two fix versions come from rule 2.
>>
>> I'm very eager to move this discussion forward, so feel free to reach out
>> on or off list if I can help with anything.
>>
>
>
> I think it is good practice to set multiple fix versions. However, it
> might take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

In the absence of further comments, I've pushed this text to a new "Release
Versioning" page on the website. I think svnpubsub automatically builds and
pushes for us now, but not 100% sure.

Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1
version updates. I'm going to be on vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.

Best,
Andrew

On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I've written up the proposal from my initial reply in a GDoc. I found one
> bug in the rules when working through my example again, and also
> incorporated Akira's correction. Thanks all for the discussion so far!
>
>
> https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> Inline.
>>
>>
>>>
>>>> BTW, I never see we have a clear definition for alpha release. It is
>>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>>> but sometimes means unstable in production quality (2.7.0). I think we
>>>> should clearly define it with major consensus so user won't
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>>    - Early version for testing - integration with downstream, deployment
>>    etc.
>>    - Not feature complete
>>    - No compatibility guarantees yet
>>
>> Beta:
>>
>>    - Feature complete
>>    - API compatibility guaranteed
>>    - Need clear definition for other kinds of compatibility (wire,
>>    client-dependencies, server-dependencies etc.)
>>    - Not ready for production deployments
>>
>> GA
>>
>>    - Ready for production
>>    - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> Also, if we treat our 3.0.0-alpha release work seriously, we should
>>>> also think about trunk's version number issue (bump up to 4.0.0-alpha?) or
>>>> there could be no room for 3.0 incompatible feature/bits soon.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

In the absence of further comments, I've pushed this text to a new "Release
Versioning" page on the website. I think svnpubsub automatically builds and
pushes for us now, but not 100% sure.

Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1
version updates. I'm going to be on vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.

Best,
Andrew

On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I've written up the proposal from my initial reply in a GDoc. I found one
> bug in the rules when working through my example again, and also
> incorporated Akira's correction. Thanks all for the discussion so far!
>
>
> https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> Inline.
>>
>>
>>>
>>>> BTW, I never see we have a clear definition for alpha release. It is
>>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>>> but sometimes means unstable in production quality (2.7.0). I think we
>>>> should clearly define it with major consensus so user won't
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>>    - Early version for testing - integration with downstream, deployment
>>    etc.
>>    - Not feature complete
>>    - No compatibility guarantees yet
>>
>> Beta:
>>
>>    - Feature complete
>>    - API compatibility guaranteed
>>    - Need clear definition for other kinds of compatibility (wire,
>>    client-dependencies, server-dependencies etc.)
>>    - Not ready for production deployments
>>
>> GA
>>
>>    - Ready for production
>>    - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> Also, if we treat our 3.0.0-alpha release work seriously, we should
>>>> also think about trunk's version number issue (bump up to 4.0.0-alpha?) or
>>>> there could be no room for 3.0 incompatible feature/bits soon.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

In the absence of further comments, I've pushed this text to a new "Release
Versioning" page on the website. I think svnpubsub automatically builds and
pushes for us now, but not 100% sure.

Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1
version updates. I'm going to be on vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.

Best,
Andrew

On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I've written up the proposal from my initial reply in a GDoc. I found one
> bug in the rules when working through my example again, and also
> incorporated Akira's correction. Thanks all for the discussion so far!
>
>
> https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> Inline.
>>
>>
>>>
>>>> BTW, I never see we have a clear definition for alpha release. It is
>>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>>> but sometimes means unstable in production quality (2.7.0). I think we
>>>> should clearly define it with major consensus so user won't
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>>    - Early version for testing - integration with downstream, deployment
>>    etc.
>>    - Not feature complete
>>    - No compatibility guarantees yet
>>
>> Beta:
>>
>>    - Feature complete
>>    - API compatibility guaranteed
>>    - Need clear definition for other kinds of compatibility (wire,
>>    client-dependencies, server-dependencies etc.)
>>    - Not ready for production deployments
>>
>> GA
>>
>>    - Ready for production
>>    - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> Also, if we treat our 3.0.0-alpha release work seriously, we should
>>>> also think about trunk's version number issue (bump up to 4.0.0-alpha?) or
>>>> there could be no room for 3.0 incompatible feature/bits soon.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

In the absence of further comments, I've pushed this text to a new "Release
Versioning" page on the website. I think svnpubsub automatically builds and
pushes for us now, but not 100% sure.

Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1
version updates. I'm going to be on vacation until the 15th, but will
tackle this when I get back. The bulk updates will also be floowed with a
wide-distribution email reminder about how to appropriately set fix
versions.

Best,
Andrew

On Thu, Jul 28, 2016 at 4:46 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I've written up the proposal from my initial reply in a GDoc. I found one
> bug in the rules when working through my example again, and also
> incorporated Akira's correction. Thanks all for the discussion so far!
>
>
> https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit
>
> Ping me if you'd like edit/comment privs, or send comments to this thread.
>
> I'm eager to close on this so we can keeping pushing on the 2.8.0 and
> 3.0.0-alpha1 releases. I'd like to post this content somewhere official
> early next week, so if you have additional feedback, please keep it coming.
>
> Best,
> Andrew
>
> On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
>
>> Inline.
>>
>>
>>>
>>>> BTW, I never see we have a clear definition for alpha release. It is
>>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>>> but sometimes means unstable in production quality (2.7.0). I think we
>>>> should clearly define it with major consensus so user won't
>>>> misunderstanding the risky here.
>>>>
>>>
>>> These are the definitions of "alpha" and "beta" used leading up to the
>>> 2.2 GA release, so it's not something new. These are also the normal
>>> industry definitions. Alpha means no API compatibility guarantees, early
>>> software. Beta means API compatible, but still some bugs.
>>>
>>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>>> releases post-2.2 GA. The thinking was that everything after would be
>>> compatible and thus (at the least) never alpha. I think this is why the
>>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>>> we could have just called 2.7.0 "beta".
>>>
>>> I think this would be good to have in our compat guidelines or
>>> somewhere. Happy to work with Karthik/Vinod/others on this.
>>>
>>
>> I am not sure if we formally defined the terms "alpha" and "beta" for
>> Hadoop 2, but my understanding of them agrees with the general definitions
>> on the web.
>>
>> Alpha:
>>
>>    - Early version for testing - integration with downstream, deployment
>>    etc.
>>    - Not feature complete
>>    - No compatibility guarantees yet
>>
>> Beta:
>>
>>    - Feature complete
>>    - API compatibility guaranteed
>>    - Need clear definition for other kinds of compatibility (wire,
>>    client-dependencies, server-dependencies etc.)
>>    - Not ready for production deployments
>>
>> GA
>>
>>    - Ready for production
>>    - All the usual compatibility guarantees apply.
>>
>> If there is general agreement, I can work towards getting this into our
>> documentation.
>>
>>
>>>
>>>> Also, if we treat our 3.0.0-alpha release work seriously, we should
>>>> also think about trunk's version number issue (bump up to 4.0.0-alpha?) or
>>>> there could be no room for 3.0 incompatible feature/bits soon.
>>>>
>>>> While we're still in alpha for 3.0.0, there's no need for a separate
>>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>>
>>
>> Branching at beta time seems reasonable.
>>
>> Overall, are there any incompatible changes on trunk that we wouldn't be
>> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
>> those bits ever?
>>
>>
>>>
>>> Best,
>>> Andrew
>>>
>>
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I've written up the proposal from my initial reply in a GDoc. I found one
bug in the rules when working through my example again, and also
incorporated Akira's correction. Thanks all for the discussion so far!

https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit

Ping me if you'd like edit/comment privs, or send comments to this thread.

I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.

Best,
Andrew

On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Inline.
>
>
>>
>>> BTW, I never see we have a clear definition for alpha release. It is
>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>> but sometimes means unstable in production quality (2.7.0). I think we
>>> should clearly define it with major consensus so user won't
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
>    - Early version for testing - integration with downstream, deployment
>    etc.
>    - Not feature complete
>    - No compatibility guarantees yet
>
> Beta:
>
>    - Feature complete
>    - API compatibility guaranteed
>    - Need clear definition for other kinds of compatibility (wire,
>    client-dependencies, server-dependencies etc.)
>    - Not ready for production deployments
>
> GA
>
>    - Ready for production
>    - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>>> could be no room for 3.0 incompatible feature/bits soon.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I've written up the proposal from my initial reply in a GDoc. I found one
bug in the rules when working through my example again, and also
incorporated Akira's correction. Thanks all for the discussion so far!

https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit

Ping me if you'd like edit/comment privs, or send comments to this thread.

I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.

Best,
Andrew

On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Inline.
>
>
>>
>>> BTW, I never see we have a clear definition for alpha release. It is
>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>> but sometimes means unstable in production quality (2.7.0). I think we
>>> should clearly define it with major consensus so user won't
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
>    - Early version for testing - integration with downstream, deployment
>    etc.
>    - Not feature complete
>    - No compatibility guarantees yet
>
> Beta:
>
>    - Feature complete
>    - API compatibility guaranteed
>    - Need clear definition for other kinds of compatibility (wire,
>    client-dependencies, server-dependencies etc.)
>    - Not ready for production deployments
>
> GA
>
>    - Ready for production
>    - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>>> could be no room for 3.0 incompatible feature/bits soon.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I've written up the proposal from my initial reply in a GDoc. I found one
bug in the rules when working through my example again, and also
incorporated Akira's correction. Thanks all for the discussion so far!

https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit

Ping me if you'd like edit/comment privs, or send comments to this thread.

I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.

Best,
Andrew

On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Inline.
>
>
>>
>>> BTW, I never see we have a clear definition for alpha release. It is
>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>> but sometimes means unstable in production quality (2.7.0). I think we
>>> should clearly define it with major consensus so user won't
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
>    - Early version for testing - integration with downstream, deployment
>    etc.
>    - Not feature complete
>    - No compatibility guarantees yet
>
> Beta:
>
>    - Feature complete
>    - API compatibility guaranteed
>    - Need clear definition for other kinds of compatibility (wire,
>    client-dependencies, server-dependencies etc.)
>    - Not ready for production deployments
>
> GA
>
>    - Ready for production
>    - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>>> could be no room for 3.0 incompatible feature/bits soon.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I've written up the proposal from my initial reply in a GDoc. I found one
bug in the rules when working through my example again, and also
incorporated Akira's correction. Thanks all for the discussion so far!

https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit

Ping me if you'd like edit/comment privs, or send comments to this thread.

I'm eager to close on this so we can keeping pushing on the 2.8.0 and
3.0.0-alpha1 releases. I'd like to post this content somewhere official
early next week, so if you have additional feedback, please keep it coming.

Best,
Andrew

On Thu, Jul 28, 2016 at 3:01 PM, Karthik Kambatla <ka...@cloudera.com>
wrote:

> Inline.
>
>
>>
>>> BTW, I never see we have a clear definition for alpha release. It is
>>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>>> but sometimes means unstable in production quality (2.7.0). I think we
>>> should clearly define it with major consensus so user won't
>>> misunderstanding the risky here.
>>>
>>
>> These are the definitions of "alpha" and "beta" used leading up to the
>> 2.2 GA release, so it's not something new. These are also the normal
>> industry definitions. Alpha means no API compatibility guarantees, early
>> software. Beta means API compatible, but still some bugs.
>>
>> If anything, we never defined the terms "alpha" and "beta" for 2.x
>> releases post-2.2 GA. The thinking was that everything after would be
>> compatible and thus (at the least) never alpha. I think this is why the
>> website talks about the 2.7.x line as "stable" or "unstable" instead, but
>> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
>> we could have just called 2.7.0 "beta".
>>
>> I think this would be good to have in our compat guidelines or somewhere.
>> Happy to work with Karthik/Vinod/others on this.
>>
>
> I am not sure if we formally defined the terms "alpha" and "beta" for
> Hadoop 2, but my understanding of them agrees with the general definitions
> on the web.
>
> Alpha:
>
>    - Early version for testing - integration with downstream, deployment
>    etc.
>    - Not feature complete
>    - No compatibility guarantees yet
>
> Beta:
>
>    - Feature complete
>    - API compatibility guaranteed
>    - Need clear definition for other kinds of compatibility (wire,
>    client-dependencies, server-dependencies etc.)
>    - Not ready for production deployments
>
> GA
>
>    - Ready for production
>    - All the usual compatibility guarantees apply.
>
> If there is general agreement, I can work towards getting this into our
> documentation.
>
>
>>
>>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>>> could be no room for 3.0 incompatible feature/bits soon.
>>>
>>> While we're still in alpha for 3.0.0, there's no need for a separate
>> 4.0.0 version since there's no guarantee of API compatibility. I plan to
>> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
>> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>>
>
> Branching at beta time seems reasonable.
>
> Overall, are there any incompatible changes on trunk that we wouldn't be
> comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
> those bits ever?
>
>
>>
>> Best,
>> Andrew
>>
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.


>
>> BTW, I never see we have a clear definition for alpha release. It is
>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>> but sometimes means unstable in production quality (2.7.0). I think we
>> should clearly define it with major consensus so user won't
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>

I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.

Alpha:

   - Early version for testing - integration with downstream, deployment
   etc.
   - Not feature complete
   - No compatibility guarantees yet

Beta:

   - Feature complete
   - API compatibility guaranteed
   - Need clear definition for other kinds of compatibility (wire,
   client-dependencies, server-dependencies etc.)
   - Not ready for production deployments

GA

   - Ready for production
   - All the usual compatibility guarantees apply.

If there is general agreement, I can work towards getting this into our
documentation.


>
>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>> could be no room for 3.0 incompatible feature/bits soon.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>

Branching at beta time seems reasonable.

Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.


>
>> BTW, I never see we have a clear definition for alpha release. It is
>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>> but sometimes means unstable in production quality (2.7.0). I think we
>> should clearly define it with major consensus so user won't
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>

I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.

Alpha:

   - Early version for testing - integration with downstream, deployment
   etc.
   - Not feature complete
   - No compatibility guarantees yet

Beta:

   - Feature complete
   - API compatibility guaranteed
   - Need clear definition for other kinds of compatibility (wire,
   client-dependencies, server-dependencies etc.)
   - Not ready for production deployments

GA

   - Ready for production
   - All the usual compatibility guarantees apply.

If there is general agreement, I can work towards getting this into our
documentation.


>
>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>> could be no room for 3.0 incompatible feature/bits soon.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>

Branching at beta time seems reasonable.

Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.


>
>> BTW, I never see we have a clear definition for alpha release. It is
>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>> but sometimes means unstable in production quality (2.7.0). I think we
>> should clearly define it with major consensus so user won't
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>

I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.

Alpha:

   - Early version for testing - integration with downstream, deployment
   etc.
   - Not feature complete
   - No compatibility guarantees yet

Beta:

   - Feature complete
   - API compatibility guaranteed
   - Need clear definition for other kinds of compatibility (wire,
   client-dependencies, server-dependencies etc.)
   - Not ready for production deployments

GA

   - Ready for production
   - All the usual compatibility guarantees apply.

If there is general agreement, I can work towards getting this into our
documentation.


>
>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>> could be no room for 3.0 incompatible feature/bits soon.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>

Branching at beta time seems reasonable.

Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.


>
>> BTW, I never see we have a clear definition for alpha release. It is
>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>> but sometimes means unstable in production quality (2.7.0). I think we
>> should clearly define it with major consensus so user won't
>> misunderstanding the risky here.
>>
>
> These are the definitions of "alpha" and "beta" used leading up to the 2.2
> GA release, so it's not something new. These are also the normal industry
> definitions. Alpha means no API compatibility guarantees, early software.
> Beta means API compatible, but still some bugs.
>
> If anything, we never defined the terms "alpha" and "beta" for 2.x
> releases post-2.2 GA. The thinking was that everything after would be
> compatible and thus (at the least) never alpha. I think this is why the
> website talks about the 2.7.x line as "stable" or "unstable" instead, but
> since I think we still guarantee API compatibility between 2.7.0 and 2.7.1,
> we could have just called 2.7.0 "beta".
>
> I think this would be good to have in our compat guidelines or somewhere.
> Happy to work with Karthik/Vinod/others on this.
>

I am not sure if we formally defined the terms "alpha" and "beta" for
Hadoop 2, but my understanding of them agrees with the general definitions
on the web.

Alpha:

   - Early version for testing - integration with downstream, deployment
   etc.
   - Not feature complete
   - No compatibility guarantees yet

Beta:

   - Feature complete
   - API compatibility guaranteed
   - Need clear definition for other kinds of compatibility (wire,
   client-dependencies, server-dependencies etc.)
   - Not ready for production deployments

GA

   - Ready for production
   - All the usual compatibility guarantees apply.

If there is general agreement, I can work towards getting this into our
documentation.


>
>> Also, if we treat our 3.0.0-alpha release work seriously, we should also
>> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
>> could be no room for 3.0 incompatible feature/bits soon.
>>
>> While we're still in alpha for 3.0.0, there's no need for a separate
> 4.0.0 version since there's no guarantee of API compatibility. I plan to
> cut a branch-3 for the beta period, at which point we'll upgrade trunk to
> 4.0.0-alpha1. This is something we discussed on another mailing list thread.
>

Branching at beta time seems reasonable.

Overall, are there any incompatible changes on trunk that we wouldn't be
comfortable shipping in 3.0.0. If yes, do we feel comfortable shipping
those bits ever?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Junping, thanks for sharing your thoughts, inline,

On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> wrote:

> Thanks Vinod for bringing up this topic for discussion. I share the same
> concern here from my previous experience and I doubt some simple rules
> proposed below could make life easier.
>
> > The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
> versions.
> > Allen's historical perspective is that we've based each minor or major
> > release off of the previous minor release. So, 2.8.0 would be based off
> of
> > 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would
> also
> > be based off of 2.7.0. This also makes sense from a user POV; someone on
> a
> > 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
> to
> > see what's changed.
> This is not correct - not reflecting the past and not helpful for the
> future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
> 2.7.3 (in case 2.8.0 is not there).
> In the past, for example, when we cut off 2.7, we already have 2.6.0 and
> 2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
> future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
> 3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
> unnecessary to do everything from scratch (3.0.0-alpha).
>

Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.

Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.

One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.

Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.


> So the rule here should be: a new major or minor release should come from
> a release:
> 1. tag with stable
> 2. released latest
> 3. with maximum version number
> If condition 2 and 3 get conflicts, we should give priority to 3. For
> example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
> and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
> based on 2.8.0 instead of 2.7.4.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.

Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.

I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.

Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.


> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> I don't think setting version tags to be more than 3 is a good practice.
> The example above means we need to backport this patch to 5 branches which
> make our committers' life really tough - it requires more effort of
> committing a patch and also increases the risky of bugs that caused by
> backport. Given realistic community review bandwidth (please check another
> thread from Chris D.), I strongly suggest we keep active release train to
> be less than 3, so we can have 2 stable release or 1 stable release + 1
> alpha release in releasing.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.


> BTW, I never see we have a clear definition for alpha release. It is
> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
> but sometimes means unstable in production quality (2.7.0). I think we
> should clearly define it with major consensus so user won't
> misunderstanding the risky here.
>

These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.

If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".

I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.


> Also, if we treat our 3.0.0-alpha release work seriously, we should also
> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
> could be no room for 3.0 incompatible feature/bits soon.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Junping, thanks for sharing your thoughts, inline,

On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> wrote:

> Thanks Vinod for bringing up this topic for discussion. I share the same
> concern here from my previous experience and I doubt some simple rules
> proposed below could make life easier.
>
> > The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
> versions.
> > Allen's historical perspective is that we've based each minor or major
> > release off of the previous minor release. So, 2.8.0 would be based off
> of
> > 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would
> also
> > be based off of 2.7.0. This also makes sense from a user POV; someone on
> a
> > 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
> to
> > see what's changed.
> This is not correct - not reflecting the past and not helpful for the
> future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
> 2.7.3 (in case 2.8.0 is not there).
> In the past, for example, when we cut off 2.7, we already have 2.6.0 and
> 2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
> future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
> 3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
> unnecessary to do everything from scratch (3.0.0-alpha).
>

Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.

Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.

One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.

Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.


> So the rule here should be: a new major or minor release should come from
> a release:
> 1. tag with stable
> 2. released latest
> 3. with maximum version number
> If condition 2 and 3 get conflicts, we should give priority to 3. For
> example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
> and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
> based on 2.8.0 instead of 2.7.4.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.

Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.

I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.

Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.


> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> I don't think setting version tags to be more than 3 is a good practice.
> The example above means we need to backport this patch to 5 branches which
> make our committers' life really tough - it requires more effort of
> committing a patch and also increases the risky of bugs that caused by
> backport. Given realistic community review bandwidth (please check another
> thread from Chris D.), I strongly suggest we keep active release train to
> be less than 3, so we can have 2 stable release or 1 stable release + 1
> alpha release in releasing.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.


> BTW, I never see we have a clear definition for alpha release. It is
> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
> but sometimes means unstable in production quality (2.7.0). I think we
> should clearly define it with major consensus so user won't
> misunderstanding the risky here.
>

These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.

If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".

I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.


> Also, if we treat our 3.0.0-alpha release work seriously, we should also
> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
> could be no room for 3.0 incompatible feature/bits soon.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Junping, thanks for sharing your thoughts, inline,

On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> wrote:

> Thanks Vinod for bringing up this topic for discussion. I share the same
> concern here from my previous experience and I doubt some simple rules
> proposed below could make life easier.
>
> > The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
> versions.
> > Allen's historical perspective is that we've based each minor or major
> > release off of the previous minor release. So, 2.8.0 would be based off
> of
> > 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would
> also
> > be based off of 2.7.0. This also makes sense from a user POV; someone on
> a
> > 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
> to
> > see what's changed.
> This is not correct - not reflecting the past and not helpful for the
> future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
> 2.7.3 (in case 2.8.0 is not there).
> In the past, for example, when we cut off 2.7, we already have 2.6.0 and
> 2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
> future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
> 3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
> unnecessary to do everything from scratch (3.0.0-alpha).
>

Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.

Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.

One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.

Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.


> So the rule here should be: a new major or minor release should come from
> a release:
> 1. tag with stable
> 2. released latest
> 3. with maximum version number
> If condition 2 and 3 get conflicts, we should give priority to 3. For
> example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
> and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
> based on 2.8.0 instead of 2.7.4.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.

Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.

I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.

Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.


> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> I don't think setting version tags to be more than 3 is a good practice.
> The example above means we need to backport this patch to 5 branches which
> make our committers' life really tough - it requires more effort of
> committing a patch and also increases the risky of bugs that caused by
> backport. Given realistic community review bandwidth (please check another
> thread from Chris D.), I strongly suggest we keep active release train to
> be less than 3, so we can have 2 stable release or 1 stable release + 1
> alpha release in releasing.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.


> BTW, I never see we have a clear definition for alpha release. It is
> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
> but sometimes means unstable in production quality (2.7.0). I think we
> should clearly define it with major consensus so user won't
> misunderstanding the risky here.
>

These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.

If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".

I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.


> Also, if we treat our 3.0.0-alpha release work seriously, we should also
> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
> could be no room for 3.0 incompatible feature/bits soon.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Hi Junping, thanks for sharing your thoughts, inline,

On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <ju...@apache.org> wrote:

> Thanks Vinod for bringing up this topic for discussion. I share the same
> concern here from my previous experience and I doubt some simple rules
> proposed below could make life easier.
>
> > The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
> versions.
> > Allen's historical perspective is that we've based each minor or major
> > release off of the previous minor release. So, 2.8.0 would be based off
> of
> > 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would
> also
> > be based off of 2.7.0. This also makes sense from a user POV; someone on
> a
> > 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
> to
> > see what's changed.
> This is not correct - not reflecting the past and not helpful for the
> future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
> 2.7.3 (in case 2.8.0 is not there).
> In the past, for example, when we cut off 2.7, we already have 2.6.0 and
> 2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
> future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
> 3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
> unnecessary to do everything from scratch (3.0.0-alpha).
>

Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite
accurate. However your point does hold for 2.5.2 -> 2.6.0.

Vinod already described this earlier, where for a while we only had a
single chronological release line. Now though, we have the concurrent 2.6.x
and 2.7.x release lines, which do fix versions independently.

One goal here is a versioning scheme that extends this concurrency to
additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make
sense to have a global ordering of releases, since not all patches belong
in all branches. It also poses additional coordination cost for release
management, particularly since it's hard to predict release timings.

Another goal is a scheme that is easy for users to understand. I believe
the above scheme accurately encodes the versioning system used by most
other enterprise software.


> So the rule here should be: a new major or minor release should come from
> a release:
> 1. tag with stable
> 2. released latest
> 3. with maximum version number
> If condition 2 and 3 get conflicts, we should give priority to 3. For
> example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
> and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
> based on 2.8.0 instead of 2.7.4.
>
> These rules seem to require a high degree of coordination when it comes to
release ordering, but one goal is to reduce coordination. For example, the
2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release."
We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We
also don't know the release ordering of 2.7.4 and 2.8.0.

Given the uncertainty around release timing and stability, it's
advantageous to avoid basing versioning on these two pieces of information.
With these rules, a changes in stability or release ordering means we need
to update JIRA fix versions.

I also didn't quite follow your example, since I assume that 2.8.0 will
*not* be marked stable similar to how 2.7.0 is not stable. If this is true,
does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4
(the latest stable release)? That seems confusing given the presence of
2.8.0.

Could you elaborate on what you see as the advantages of this scheme from a
user POV? It seems like users now need to be aware of the total ordering
and also stability of releases to know what changelogs to read. And as
described previously, it's not how other enterprise software versioning
works.


> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> I don't think setting version tags to be more than 3 is a good practice.
> The example above means we need to backport this patch to 5 branches which
> make our committers' life really tough - it requires more effort of
> committing a patch and also increases the risky of bugs that caused by
> backport. Given realistic community review bandwidth (please check another
> thread from Chris D.), I strongly suggest we keep active release train to
> be less than 3, so we can have 2 stable release or 1 stable release + 1
> alpha release in releasing.
>
> We already need to backport to many branches, setting some more fix
versions doesn't change that. Setting more fix versions is also not related
to review bandwidth, particularly in this case since things normally land
in trunk first. It's also not related to the number of concurrent releases,
since release-related effort is not zero-sum.


> BTW, I never see we have a clear definition for alpha release. It is
> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
> but sometimes means unstable in production quality (2.7.0). I think we
> should clearly define it with major consensus so user won't
> misunderstanding the risky here.
>

These are the definitions of "alpha" and "beta" used leading up to the 2.2
GA release, so it's not something new. These are also the normal industry
definitions. Alpha means no API compatibility guarantees, early software.
Beta means API compatible, but still some bugs.

If anything, we never defined the terms "alpha" and "beta" for 2.x releases
post-2.2 GA. The thinking was that everything after would be compatible and
thus (at the least) never alpha. I think this is why the website talks
about the 2.7.x line as "stable" or "unstable" instead, but since I think
we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have
just called 2.7.0 "beta".

I think this would be good to have in our compat guidelines or somewhere.
Happy to work with Karthik/Vinod/others on this.


> Also, if we treat our 3.0.0-alpha release work seriously, we should also
> think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
> could be no room for 3.0 incompatible feature/bits soon.
>
> While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0
version since there's no guarantee of API compatibility. I plan to cut a
branch-3 for the beta period, at which point we'll upgrade trunk to
4.0.0-alpha1. This is something we discussed on another mailing list thread.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[俊平堵 <ju...@apache.org>]

Thanks Vinod for bringing up this topic for discussion. I share the same
concern here from my previous experience and I doubt some simple rules
proposed below could make life easier.

> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
to
> see what's changed.
This is not correct - not reflecting the past and not helpful for the
future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
2.7.3 (in case 2.8.0 is not there).
In the past, for example, when we cut off 2.7, we already have 2.6.0 and
2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
unnecessary to do everything from scratch (3.0.0-alpha). So the rule here
should be: a new major or minor release should come from a release:
1. tag with stable
2. released latest
3. with maximum version number
If condition 2 and 3 get conflicts, we should give priority to 3. For
example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
based on 2.8.0 instead of 2.7.4.


> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
I don't think setting version tags to be more than 3 is a good practice.
The example above means we need to backport this patch to 5 branches which
make our committers' life really tough - it requires more effort of
committing a patch and also increases the risky of bugs that caused by
backport. Given realistic community review bandwidth (please check another
thread from Chris D.), I strongly suggest we keep active release train to
be less than 3, so we can have 2 stable release or 1 stable release + 1
alpha release in releasing.

BTW, I never see we have a clear definition for alpha release. It is
previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
but sometimes means unstable in production quality (2.7.0). I think we
should clearly define it with major consensus so user won't
misunderstanding the risky here.
Also, if we treat our 3.0.0-alpha release work seriously, we should also
think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
could be no room for 3.0 incompatible feature/bits soon.

Just 2 cents.

Thanks,

Junping

2016-07-27 15:34 GMT+01:00 Karthik Kambatla <ka...@cloudera.com>:

> Inline.
>
> > 1) Set the fix version for all a.b.c versions, where c > 0.
> > 2) For each major release line, set the lowest a.b.0 version.
> >
>
> Sounds reasonable.
>
>
> >
> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> > a.b.c versions, with alpha1 being the a.b.0 release.
> >
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
> >
> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> >
> > I'm very eager to move this discussion forward, so feel free to reach out
> > on or off list if I can help with anything.
> >
>
>
> I think it is good practice to set multiple fix versions. However, it might
> take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
> >
> > Best,
> > Andrew
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[俊平堵 <ju...@apache.org>]

Thanks Vinod for bringing up this topic for discussion. I share the same
concern here from my previous experience and I doubt some simple rules
proposed below could make life easier.

> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
to
> see what's changed.
This is not correct - not reflecting the past and not helpful for the
future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
2.7.3 (in case 2.8.0 is not there).
In the past, for example, when we cut off 2.7, we already have 2.6.0 and
2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
unnecessary to do everything from scratch (3.0.0-alpha). So the rule here
should be: a new major or minor release should come from a release:
1. tag with stable
2. released latest
3. with maximum version number
If condition 2 and 3 get conflicts, we should give priority to 3. For
example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
based on 2.8.0 instead of 2.7.4.


> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
I don't think setting version tags to be more than 3 is a good practice.
The example above means we need to backport this patch to 5 branches which
make our committers' life really tough - it requires more effort of
committing a patch and also increases the risky of bugs that caused by
backport. Given realistic community review bandwidth (please check another
thread from Chris D.), I strongly suggest we keep active release train to
be less than 3, so we can have 2 stable release or 1 stable release + 1
alpha release in releasing.

BTW, I never see we have a clear definition for alpha release. It is
previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
but sometimes means unstable in production quality (2.7.0). I think we
should clearly define it with major consensus so user won't
misunderstanding the risky here.
Also, if we treat our 3.0.0-alpha release work seriously, we should also
think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
could be no room for 3.0 incompatible feature/bits soon.

Just 2 cents.

Thanks,

Junping

2016-07-27 15:34 GMT+01:00 Karthik Kambatla <ka...@cloudera.com>:

> Inline.
>
> > 1) Set the fix version for all a.b.c versions, where c > 0.
> > 2) For each major release line, set the lowest a.b.0 version.
> >
>
> Sounds reasonable.
>
>
> >
> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> > a.b.c versions, with alpha1 being the a.b.0 release.
> >
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
> >
> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> >
> > I'm very eager to move this discussion forward, so feel free to reach out
> > on or off list if I can help with anything.
> >
>
>
> I think it is good practice to set multiple fix versions. However, it might
> take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
> >
> > Best,
> > Andrew
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[俊平堵 <ju...@apache.org>]

Thanks Vinod for bringing up this topic for discussion. I share the same
concern here from my previous experience and I doubt some simple rules
proposed below could make life easier.

> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
to
> see what's changed.
This is not correct - not reflecting the past and not helpful for the
future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
2.7.3 (in case 2.8.0 is not there).
In the past, for example, when we cut off 2.7, we already have 2.6.0 and
2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
unnecessary to do everything from scratch (3.0.0-alpha). So the rule here
should be: a new major or minor release should come from a release:
1. tag with stable
2. released latest
3. with maximum version number
If condition 2 and 3 get conflicts, we should give priority to 3. For
example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
based on 2.8.0 instead of 2.7.4.


> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
I don't think setting version tags to be more than 3 is a good practice.
The example above means we need to backport this patch to 5 branches which
make our committers' life really tough - it requires more effort of
committing a patch and also increases the risky of bugs that caused by
backport. Given realistic community review bandwidth (please check another
thread from Chris D.), I strongly suggest we keep active release train to
be less than 3, so we can have 2 stable release or 1 stable release + 1
alpha release in releasing.

BTW, I never see we have a clear definition for alpha release. It is
previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
but sometimes means unstable in production quality (2.7.0). I think we
should clearly define it with major consensus so user won't
misunderstanding the risky here.
Also, if we treat our 3.0.0-alpha release work seriously, we should also
think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
could be no room for 3.0 incompatible feature/bits soon.

Just 2 cents.

Thanks,

Junping

2016-07-27 15:34 GMT+01:00 Karthik Kambatla <ka...@cloudera.com>:

> Inline.
>
> > 1) Set the fix version for all a.b.c versions, where c > 0.
> > 2) For each major release line, set the lowest a.b.0 version.
> >
>
> Sounds reasonable.
>
>
> >
> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> > a.b.c versions, with alpha1 being the a.b.0 release.
> >
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
> >
> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> >
> > I'm very eager to move this discussion forward, so feel free to reach out
> > on or off list if I can help with anything.
> >
>
>
> I think it is good practice to set multiple fix versions. However, it might
> take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
> >
> > Best,
> > Andrew
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
>> a.b.c versions, with alpha1 being the a.b.0 release.
>>
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.

The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.

>
>> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
>> branch-2,
>> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
>> 2.7.3,
>> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
>> rule 1, and the last two fix versions come from rule 2.
>>
>> I'm very eager to move this discussion forward, so feel free to reach out
>> on or off list if I can help with anything.
>>
>
>
> I think it is good practice to set multiple fix versions. However, it
> might take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
>> a.b.c versions, with alpha1 being the a.b.0 release.
>>
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.

The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.

>
>> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
>> branch-2,
>> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
>> 2.7.3,
>> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
>> rule 1, and the last two fix versions come from rule 2.
>>
>> I'm very eager to move this discussion forward, so feel free to reach out
>> on or off list if I can help with anything.
>>
>
>
> I think it is good practice to set multiple fix versions. However, it
> might take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
>> a.b.c versions, with alpha1 being the a.b.0 release.
>>
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
Yea. It means the if you're coming from 2.7, you'd read the 3.0.0-alphas,
3.0.0-betas, and finally the 3.0.0 GA notes.

The website notes will aggregate all the alpha and beta changes leading up
to 3.0.0 GA, so is likely where users will turn to first.

>
>> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
>> branch-2,
>> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
>> 2.7.3,
>> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
>> rule 1, and the last two fix versions come from rule 2.
>>
>> I'm very eager to move this discussion forward, so feel free to reach out
>> on or off list if I can help with anything.
>>
>
>
> I think it is good practice to set multiple fix versions. However, it
> might take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
Yea, I have a script and some JIRA queries that can help with this. I'll
also plan to compare with git log contents for extra verification.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[俊平堵 <ju...@apache.org>]

Thanks Vinod for bringing up this topic for discussion. I share the same
concern here from my previous experience and I doubt some simple rules
proposed below could make life easier.

> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
to
> see what's changed.
This is not correct - not reflecting the past and not helpful for the
future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
2.7.3 (in case 2.8.0 is not there).
In the past, for example, when we cut off 2.7, we already have 2.6.0 and
2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
unnecessary to do everything from scratch (3.0.0-alpha). So the rule here
should be: a new major or minor release should come from a release:
1. tag with stable
2. released latest
3. with maximum version number
If condition 2 and 3 get conflicts, we should give priority to 3. For
example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
based on 2.8.0 instead of 2.7.4.


> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
I don't think setting version tags to be more than 3 is a good practice.
The example above means we need to backport this patch to 5 branches which
make our committers' life really tough - it requires more effort of
committing a patch and also increases the risky of bugs that caused by
backport. Given realistic community review bandwidth (please check another
thread from Chris D.), I strongly suggest we keep active release train to
be less than 3, so we can have 2 stable release or 1 stable release + 1
alpha release in releasing.

BTW, I never see we have a clear definition for alpha release. It is
previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
but sometimes means unstable in production quality (2.7.0). I think we
should clearly define it with major consensus so user won't
misunderstanding the risky here.
Also, if we treat our 3.0.0-alpha release work seriously, we should also
think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
could be no room for 3.0 incompatible feature/bits soon.

Just 2 cents.

Thanks,

Junping

2016-07-27 15:34 GMT+01:00 Karthik Kambatla <ka...@cloudera.com>:

> Inline.
>
> > 1) Set the fix version for all a.b.c versions, where c > 0.
> > 2) For each major release line, set the lowest a.b.0 version.
> >
>
> Sounds reasonable.
>
>
> >
> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> > a.b.c versions, with alpha1 being the a.b.0 release.
> >
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
> >
> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> >
> > I'm very eager to move this discussion forward, so feel free to reach out
> > on or off list if I can help with anything.
> >
>
>
> I think it is good practice to set multiple fix versions. However, it might
> take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
> >
> > Best,
> > Andrew
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.

> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>

Sounds reasonable.


>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>

Once 3.0.0 GA goes out, a user would want to see the diff from the latest
2.x.0 release (say 2.9.0).

Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
apply, and it should show up in the release notes?


>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>


I think it is good practice to set multiple fix versions. However, it might
take the committers a little bit to learn.

Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
3.0.0-alphaX version?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Akira Ajisaka <aj...@oss.nttdata.co.jp>]

Thanks Vinod and Andrew for the summary.

 > Here's an attempt at encoding this policy as a set of rules for 
setting fix
 > versions (credit to Allen):
 >
 > 1) Set the fix version for all a.b.c versions, where c > 0.
 > 2) For each major release line, set the lowest a.b.0 version.

Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we need 
to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we 
don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a 
jira. Is it right?

 > As an example, if a JIRA was committed to branch-2.6, branch-2.7, 
branch-2,
 > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 
2.7.3,
 > 2.8.0, 3.0.0-alpha1.

(nit) 2.7.3 -> 2.7.4, because branch-2.7.3 has been cut.

Regards,
Akira

On 7/27/16 06:03, Andrew Wang wrote:
> Thanks Vinod for forking the thread. Let me try and summarize what Allen
> and I talked about in the previous thread.
>
> Currently, we've been marking JIRAs with fix versions of both 2.6.x and
> 2.7.x. IIUC, the chronological ordering between these two lines is actually
> not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
> looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
> entries. This makes sense from a user POV.
>
> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
> see what's changed.
>
> Having looked at the changelogs of other enterprise software products, this
> is pretty standard.
>
> Perhaps restating the obvious, but:
>
> * For a.b.c releases, the "c"s need to be released in order.
> * For a.b.0 releases, the "b"s need to be released in order.
> * For a.0.0 releases, it comes after a specific x.y.0 release.
>
> Here's an attempt at encoding this policy as a set of rules for setting fix
> versions (credit to Allen):
>
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>
> Best,
> Andrew
>


---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.

> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>

Sounds reasonable.


>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>

Once 3.0.0 GA goes out, a user would want to see the diff from the latest
2.x.0 release (say 2.9.0).

Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
apply, and it should show up in the release notes?


>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>


I think it is good practice to set multiple fix versions. However, it might
take the committers a little bit to learn.

Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
3.0.0-alphaX version?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Akira Ajisaka <aj...@oss.nttdata.co.jp>]

Thanks Vinod and Andrew for the summary.

 > Here's an attempt at encoding this policy as a set of rules for 
setting fix
 > versions (credit to Allen):
 >
 > 1) Set the fix version for all a.b.c versions, where c > 0.
 > 2) For each major release line, set the lowest a.b.0 version.

Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we need 
to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we 
don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a 
jira. Is it right?

 > As an example, if a JIRA was committed to branch-2.6, branch-2.7, 
branch-2,
 > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 
2.7.3,
 > 2.8.0, 3.0.0-alpha1.

(nit) 2.7.3 -> 2.7.4, because branch-2.7.3 has been cut.

Regards,
Akira

On 7/27/16 06:03, Andrew Wang wrote:
> Thanks Vinod for forking the thread. Let me try and summarize what Allen
> and I talked about in the previous thread.
>
> Currently, we've been marking JIRAs with fix versions of both 2.6.x and
> 2.7.x. IIUC, the chronological ordering between these two lines is actually
> not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
> looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
> entries. This makes sense from a user POV.
>
> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
> see what's changed.
>
> Having looked at the changelogs of other enterprise software products, this
> is pretty standard.
>
> Perhaps restating the obvious, but:
>
> * For a.b.c releases, the "c"s need to be released in order.
> * For a.b.0 releases, the "b"s need to be released in order.
> * For a.0.0 releases, it comes after a specific x.y.0 release.
>
> Here's an attempt at encoding this policy as a set of rules for setting fix
> versions (credit to Allen):
>
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>
> Best,
> Andrew
>


---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.

> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>

Sounds reasonable.


>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>

Once 3.0.0 GA goes out, a user would want to see the diff from the latest
2.x.0 release (say 2.9.0).

Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
apply, and it should show up in the release notes?


>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>


I think it is good practice to set multiple fix versions. However, it might
take the committers a little bit to learn.

Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
3.0.0-alphaX version?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Akira Ajisaka <aj...@oss.nttdata.co.jp>]

Thanks Vinod and Andrew for the summary.

 > Here's an attempt at encoding this policy as a set of rules for 
setting fix
 > versions (credit to Allen):
 >
 > 1) Set the fix version for all a.b.c versions, where c > 0.
 > 2) For each major release line, set the lowest a.b.0 version.

Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we need 
to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we 
don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a 
jira. Is it right?

 > As an example, if a JIRA was committed to branch-2.6, branch-2.7, 
branch-2,
 > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 
2.7.3,
 > 2.8.0, 3.0.0-alpha1.

(nit) 2.7.3 -> 2.7.4, because branch-2.7.3 has been cut.

Regards,
Akira

On 7/27/16 06:03, Andrew Wang wrote:
> Thanks Vinod for forking the thread. Let me try and summarize what Allen
> and I talked about in the previous thread.
>
> Currently, we've been marking JIRAs with fix versions of both 2.6.x and
> 2.7.x. IIUC, the chronological ordering between these two lines is actually
> not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
> looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
> entries. This makes sense from a user POV.
>
> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
> see what's changed.
>
> Having looked at the changelogs of other enterprise software products, this
> is pretty standard.
>
> Perhaps restating the obvious, but:
>
> * For a.b.c releases, the "c"s need to be released in order.
> * For a.b.0 releases, the "b"s need to be released in order.
> * For a.0.0 releases, it comes after a specific x.y.0 release.
>
> Here's an attempt at encoding this policy as a set of rules for setting fix
> versions (credit to Allen):
>
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>
> Best,
> Andrew
>


---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

1. I probably missed something but I didn't get it how "alpha"s made their
way into release numbers again. This was discussed on several occasions and
I thought the common perception was to use just three level numbers for
release versioning and avoid branding them.
It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What is
alphaX - fourth level? I think releasing 3.0.0 and setting trunk to 3.1.0
would be perfectly in line with our current release practices.

2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
The release number is not intended to reflect historical release sequence,
but rather the point in the source tree, which it was branched off. So one
can release 2.8, 2.9, etc. after or before 3.0.

3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
think of another rule that if a release branch is not released in 3 month
it should be abandoned. Which is applicable to branch 2.8.0 and it is too
much work syncing it with branch-2.

Thanks,
--Konstantin

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

1. I probably missed something but I didn't get it how "alpha"s made their
way into release numbers again. This was discussed on several occasions and
I thought the common perception was to use just three level numbers for
release versioning and avoid branding them.
It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What is
alphaX - fourth level? I think releasing 3.0.0 and setting trunk to 3.1.0
would be perfectly in line with our current release practices.

2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
The release number is not intended to reflect historical release sequence,
but rather the point in the source tree, which it was branched off. So one
can release 2.8, 2.9, etc. after or before 3.0.

3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
think of another rule that if a release branch is not released in 3 month
it should be abandoned. Which is applicable to branch 2.8.0 and it is too
much work syncing it with branch-2.

Thanks,
--Konstantin

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Akira Ajisaka <aj...@oss.nttdata.co.jp>]

Thanks Vinod and Andrew for the summary.

 > Here's an attempt at encoding this policy as a set of rules for 
setting fix
 > versions (credit to Allen):
 >
 > 1) Set the fix version for all a.b.c versions, where c > 0.
 > 2) For each major release line, set the lowest a.b.0 version.

Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we need 
to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we 
don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a 
jira. Is it right?

 > As an example, if a JIRA was committed to branch-2.6, branch-2.7, 
branch-2,
 > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 
2.7.3,
 > 2.8.0, 3.0.0-alpha1.

(nit) 2.7.3 -> 2.7.4, because branch-2.7.3 has been cut.

Regards,
Akira

On 7/27/16 06:03, Andrew Wang wrote:
> Thanks Vinod for forking the thread. Let me try and summarize what Allen
> and I talked about in the previous thread.
>
> Currently, we've been marking JIRAs with fix versions of both 2.6.x and
> 2.7.x. IIUC, the chronological ordering between these two lines is actually
> not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
> looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
> entries. This makes sense from a user POV.
>
> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
> see what's changed.
>
> Having looked at the changelogs of other enterprise software products, this
> is pretty standard.
>
> Perhaps restating the obvious, but:
>
> * For a.b.c releases, the "c"s need to be released in order.
> * For a.b.0 releases, the "b"s need to be released in order.
> * For a.0.0 releases, it comes after a specific x.y.0 release.
>
> Here's an attempt at encoding this policy as a set of rules for setting fix
> versions (credit to Allen):
>
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>
> Best,
> Andrew
>


---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Konstantin Shvachko <sh...@gmail.com>]

1. I probably missed something but I didn't get it how "alpha"s made their
way into release numbers again. This was discussed on several occasions and
I thought the common perception was to use just three level numbers for
release versioning and avoid branding them.
It is particularly confusing to have 3.0.0-alpha1 and 3.0.0-alpha2. What is
alphaX - fourth level? I think releasing 3.0.0 and setting trunk to 3.1.0
would be perfectly in line with our current release practices.

2. I do not see any confusions with releasing 2.8.0 after 3.0.0.
The release number is not intended to reflect historical release sequence,
but rather the point in the source tree, which it was branched off. So one
can release 2.8, 2.9, etc. after or before 3.0.

3. I agree that current 3.0.0 branch can be dropped and re-cut. We may
think of another rule that if a release branch is not released in 3 month
it should be abandoned. Which is applicable to branch 2.8.0 and it is too
much work syncing it with branch-2.

Thanks,
--Konstantin

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Karthik Kambatla <ka...@cloudera.com>]

Inline.

> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>

Sounds reasonable.


>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>

Once 3.0.0 GA goes out, a user would want to see the diff from the latest
2.x.0 release (say 2.9.0).

Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
apply, and it should show up in the release notes?


>
> As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
>
> I'm very eager to move this discussion forward, so feel free to reach out
> on or off list if I can help with anything.
>


I think it is good practice to set multiple fix versions. However, it might
take the committers a little bit to learn.

Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
3.0.0-alphaX version?


>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks Vinod for forking the thread. Let me try and summarize what Allen
and I talked about in the previous thread.

Currently, we've been marking JIRAs with fix versions of both 2.6.x and
2.7.x. IIUC, the chronological ordering between these two lines is actually
not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
entries. This makes sense from a user POV.

The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
Allen's historical perspective is that we've based each minor or major
release off of the previous minor release. So, 2.8.0 would be based off of
2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
be based off of 2.7.0. This also makes sense from a user POV; someone on a
2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
see what's changed.

Having looked at the changelogs of other enterprise software products, this
is pretty standard.

Perhaps restating the obvious, but:

* For a.b.c releases, the "c"s need to be released in order.
* For a.b.0 releases, the "b"s need to be released in order.
* For a.0.0 releases, it comes after a specific x.y.0 release.

Here's an attempt at encoding this policy as a set of rules for setting fix
versions (credit to Allen):

1) Set the fix version for all a.b.c versions, where c > 0.
2) For each major release line, set the lowest a.b.0 version.

The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
a.b.c versions, with alpha1 being the a.b.0 release.

As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
rule 1, and the last two fix versions come from rule 2.

I'm very eager to move this discussion forward, so feel free to reach out
on or off list if I can help with anything.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks Vinod for forking the thread. Let me try and summarize what Allen
and I talked about in the previous thread.

Currently, we've been marking JIRAs with fix versions of both 2.6.x and
2.7.x. IIUC, the chronological ordering between these two lines is actually
not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
entries. This makes sense from a user POV.

The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
Allen's historical perspective is that we've based each minor or major
release off of the previous minor release. So, 2.8.0 would be based off of
2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
be based off of 2.7.0. This also makes sense from a user POV; someone on a
2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
see what's changed.

Having looked at the changelogs of other enterprise software products, this
is pretty standard.

Perhaps restating the obvious, but:

* For a.b.c releases, the "c"s need to be released in order.
* For a.b.0 releases, the "b"s need to be released in order.
* For a.0.0 releases, it comes after a specific x.y.0 release.

Here's an attempt at encoding this policy as a set of rules for setting fix
versions (credit to Allen):

1) Set the fix version for all a.b.c versions, where c > 0.
2) For each major release line, set the lowest a.b.0 version.

The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
a.b.c versions, with alpha1 being the a.b.0 release.

As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
rule 1, and the last two fix versions come from rule 2.

I'm very eager to move this discussion forward, so feel free to reach out
on or off list if I can help with anything.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> I think I understand a bit better, though now I ask how this date is different from the release date.

OIC. I also assume that the freezing branch cannot include the changes
between freezing date and the release date. This is for strict
ordering to ensure which is the newer. If we have lots maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.

> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.

If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily -  if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.

However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.

Best,
- Tsuyoshi

On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > Andrew: I bet many would assume it's the release date, like how Ubuntu
>> > releases are numbered.
>>
>> Good point. Maybe I confuse you because of lack of explanation.
>>
>> I assume that "branch-cut off timing" mean the timing of freezing branch
>> like when starting the release vote. It's because that the release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
>>>> we need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira. Is
>>>> it right?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> I think I understand a bit better, though now I ask how this date is different from the release date.

OIC. I also assume that the freezing branch cannot include the changes
between freezing date and the release date. This is for strict
ordering to ensure which is the newer. If we have lots maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.

> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.

If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily -  if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.

However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.

Best,
- Tsuyoshi

On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > Andrew: I bet many would assume it's the release date, like how Ubuntu
>> > releases are numbered.
>>
>> Good point. Maybe I confuse you because of lack of explanation.
>>
>> I assume that "branch-cut off timing" mean the timing of freezing branch
>> like when starting the release vote. It's because that the release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
>>>> we need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira. Is
>>>> it right?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Wangda Tan <wh...@gmail.com>]

Thanks Andrew for sharing your thoughts,

It looks better if we can put multiple versions on the fix version, with
that we can at least do some queries on JIRA to check the issues like "in
branch-2.6.5 but not in branch-2.7.4".

I still have a couple of questions:

*1) How CHANGES.txt (or release note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.

For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.

However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.

To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.

Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.

*2) Do we need to update historical JIRAs?*

It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.

Thoughts?

Wangda

On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > Andrew: I bet many would assume it's the release date, like how Ubuntu
> > releases are numbered.
> >
> > Good point. Maybe I confuse you because of lack of explanation.
> >
> > I assume that "branch-cut off timing" mean the timing of freezing branch
> > like when starting the release vote. It's because that the release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
> we
> >>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and
> we
> >>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a
> jira.
> >>> Is it right?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Wangda Tan <wh...@gmail.com>]

Thanks Andrew for sharing your thoughts,

It looks better if we can put multiple versions on the fix version, with
that we can at least do some queries on JIRA to check the issues like "in
branch-2.6.5 but not in branch-2.7.4".

I still have a couple of questions:

*1) How CHANGES.txt (or release note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.

For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.

However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.

To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.

Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.

*2) Do we need to update historical JIRAs?*

It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.

Thoughts?

Wangda

On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > Andrew: I bet many would assume it's the release date, like how Ubuntu
> > releases are numbered.
> >
> > Good point. Maybe I confuse you because of lack of explanation.
> >
> > I assume that "branch-cut off timing" mean the timing of freezing branch
> > like when starting the release vote. It's because that the release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
> we
> >>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and
> we
> >>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a
> jira.
> >>> Is it right?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> I think I understand a bit better, though now I ask how this date is different from the release date.

OIC. I also assume that the freezing branch cannot include the changes
between freezing date and the release date. This is for strict
ordering to ensure which is the newer. If we have lots maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.

> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.

If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily -  if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.

However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.

Best,
- Tsuyoshi

On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > Andrew: I bet many would assume it's the release date, like how Ubuntu
>> > releases are numbered.
>>
>> Good point. Maybe I confuse you because of lack of explanation.
>>
>> I assume that "branch-cut off timing" mean the timing of freezing branch
>> like when starting the release vote. It's because that the release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
>>>> we need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira. Is
>>>> it right?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Wangda Tan <wh...@gmail.com>]

Thanks Andrew for sharing your thoughts,

It looks better if we can put multiple versions on the fix version, with
that we can at least do some queries on JIRA to check the issues like "in
branch-2.6.5 but not in branch-2.7.4".

I still have a couple of questions:

*1) How CHANGES.txt (or release note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.

For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.

However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.

To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.

Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.

*2) Do we need to update historical JIRAs?*

It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.

Thoughts?

Wangda

On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > Andrew: I bet many would assume it's the release date, like how Ubuntu
> > releases are numbered.
> >
> > Good point. Maybe I confuse you because of lack of explanation.
> >
> > I assume that "branch-cut off timing" mean the timing of freezing branch
> > like when starting the release vote. It's because that the release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
> we
> >>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and
> we
> >>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a
> jira.
> >>> Is it right?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Wangda Tan <wh...@gmail.com>]

Thanks Andrew for sharing your thoughts,

It looks better if we can put multiple versions on the fix version, with
that we can at least do some queries on JIRA to check the issues like "in
branch-2.6.5 but not in branch-2.7.4".

I still have a couple of questions:

*1) How CHANGES.txt (or release note) should look like?*
Not sure if this is discussed before. Previously we put the *next* release
version of earliest branch to CHANGES.txt. However, this could be confusing
and need a lot of manual works.

For example, we have two parallel release branches: branch-2.6.5 and
branch-2.7.4. When we need to backport a commit X in branch-2.7.4 to
branch-2.6.5, we will update CHANGES.txt in branch-2.7.4 to say this commit
X is included by Hadoop-2.6.5.

However, if we release Hadoop-2.7.4 before Hadoop-2.6.5, user will find the
Hadoop-2.6.5 is not released yet.

To me, we should put the fix version in CHANGES.txt to the released Hadoop
from the earliest branch, in the above example, Hadoop-2.7.4 should be the
fix version of commit X in release note of Hadoop-2.7.4.

Instead, I suggest to add a suffix ("released") to the fix version after
release is done. So the release note generator can do query easier, and
other user of JIRA can benefit from this to understand which releases
include a given JIRA.

*2) Do we need to update historical JIRAs?*

It's better to make a consistent rule for active release branches (to me
they're branch-2.6 and up). So it will be better to update fix version for
all resolved JIRAs in release branches.

Thoughts?

Wangda

On Tue, Jul 26, 2016 at 11:40 PM, Andrew Wang <an...@cloudera.com>
wrote:

> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later
> 2.7.c release (found easily since a.b.c releases are ordered), and when
> jumping to a new minor or major version, any version released
> chronologically after 2.7.3. This means you need to check the website, but
> given that this is the way most enterprise software is versioned, I think
> it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>
> > > Andrew: I bet many would assume it's the release date, like how Ubuntu
> > releases are numbered.
> >
> > Good point. Maybe I confuse you because of lack of explanation.
> >
> > I assume that "branch-cut off timing" mean the timing of freezing branch
> > like when starting the release vote. It's because that the release can
> > be delayed after the release pass. Does it make sense to you?
> >
> > > Even if we have the branch-cut date in the version string, devs still
> > need to be aware of other branches and backport appropriately.
> >
> > Yes, you're right. The good point of including date is that we can
> declare
> > which version includes the latest changes. It helps users, not devs
> > basically, to decide which version users will use: e.g. if
> > 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> > 2.7.3-20160701, she can update their cluster 2.8.1, which include bug
> fixes
> > against 2.7.3. Please let me know if I have some missing points.
> >
> > Thanks,
> > - Tsuyoshi
> >
> > On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com>
> wrote:
> >
> >> Thanks for replies Akira and Tsuyoshi, inline:
> >>
> >> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
> we
> >>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and
> we
> >>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a
> jira.
> >>> Is it right?
> >>
> >>
> >> Yes, correct.
> >>
> >>
> >>> Tsuyoshi: My suggestion is adding the date when branch cut is done:
> like
> >>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
> >>>
> >>> Pros:-) It's totally ordered. If we have a policy such as backporting
> >>> to maintainance branches after the date, users can find that which
> >>> version
> >>> is cutting edge. In the example of above, 2.8.0-20160730 can include
> bug
> >>> fixes which is not included in 3.0.0-alpha1-20160724.
> >>>
> >>> Cons:-( A bit redundant.
> >>>
> >>> Could you elaborate on the problem this scheme addresses? We always
> want
> >> our releases, when ordered chronologically, to incorporate all the known
> >> relevant bug fixes. Even if we have the branch-cut date in the version
> >> string, devs still need to be aware of other branches and backport
> >> appropriately.
> >>
> >> Given that branch cuts and releases might not happen in the same order
> >> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be
> confusing
> >> for users. I bet many would assume it's the release date, like how
> Ubuntu
> >> releases are numbered.
> >>
> >> Best,
> >> Andrew
> >>
> >
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> I think I understand a bit better, though now I ask how this date is different from the release date.

OIC. I also assume that the freezing branch cannot include the changes
between freezing date and the release date. This is for strict
ordering to ensure which is the newer. If we have lots maintenance
branches, it helps us to understand which branches include fix a
problem of my cluster.

> I think this problem is also pretty rare in practice, since users normally upgrade to the highest maintenance release within a major/minor.

If there will be lots maintenance branches in parallel(2.6.x, 2.7.x,
2.8.x, 2.9.x, 3.0.x), we can hit this problem more easily -  if a user
uses plan to upgrade 2.7.3 cluster to 2.8.3 or 2.9.1 or 3.0.1, which
version should the user choose? This is my concern.

However, as you mentioned, we decide to reduce the number of branches
we keep maintenance, we don't need to do that.

Best,
- Tsuyoshi

On Wed, Jul 27, 2016 at 3:40 PM, Andrew Wang <an...@cloudera.com> wrote:
> I think I understand a bit better, though now I ask how this date is
> different from the release date. Based on the HowToRelease instructions, we
> set the release date to when the release vote passes. So, start of release
> vote vs. end of release vote doesn't seem that different, and these dates
> are still totally ordered.
>
> For the user in this scenario, she can upgrade from 2.7.3 to any later 2.7.c
> release (found easily since a.b.c releases are ordered), and when jumping to
> a new minor or major version, any version released chronologically after
> 2.7.3. This means you need to check the website, but given that this is the
> way most enterprise software is versioned, I think it'll be okay by users.
>
> I think this problem is also pretty rare in practice, since users normally
> upgrade to the highest maintenance release within a major/minor. Thus
> they'll only hit this if their upgrade cycle is faster than it takes for a
> change released in e.g. 2.6.x to then also be released in a 2.7.x.
>
> Best,
> Andrew
>
> On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
>>
>> > Andrew: I bet many would assume it's the release date, like how Ubuntu
>> > releases are numbered.
>>
>> Good point. Maybe I confuse you because of lack of explanation.
>>
>> I assume that "branch-cut off timing" mean the timing of freezing branch
>> like when starting the release vote. It's because that the release can be
>> delayed after the release pass. Does it make sense to you?
>>
>> > Even if we have the branch-cut date in the version string, devs still
>> > need to be aware of other branches and backport appropriately.
>>
>> Yes, you're right. The good point of including date is that we can declare
>> which version includes the latest changes. It helps users, not devs
>> basically, to decide which version users will use: e.g. if 2.8.1-20160801 is
>> released after 2.9.0-20160701 and a user uses 2.7.3-20160701, she can update
>> their cluster 2.8.1, which include bug fixes against 2.7.3. Please let me
>> know if I have some missing points.
>>
>> Thanks,
>> - Tsuyoshi
>>
>> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>>>
>>> Thanks for replies Akira and Tsuyoshi, inline:
>>>
>>>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0,
>>>> we need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira. Is
>>>> it right?
>>>
>>>
>>> Yes, correct.
>>>
>>>>
>>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>>
>>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>>> to maintainance branches after the date, users can find that which
>>>> version
>>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>>
>>>> Cons:-( A bit redundant.
>>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>>> our releases, when ordered chronologically, to incorporate all the known
>>> relevant bug fixes. Even if we have the branch-cut date in the version
>>> string, devs still need to be aware of other branches and backport
>>> appropriately.
>>>
>>> Given that branch cuts and releases might not happen in the same order
>>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>>> for users. I bet many would assume it's the release date, like how Ubuntu
>>> releases are numbered.
>>>
>>> Best,
>>> Andrew
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I think I understand a bit better, though now I ask how this date is
different from the release date. Based on the HowToRelease instructions, we
set the release date to when the release vote passes. So, start of release
vote vs. end of release vote doesn't seem that different, and these dates
are still totally ordered.

For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.

I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.

Best,
Andrew

On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:

> > Andrew: I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Good point. Maybe I confuse you because of lack of explanation.
>
> I assume that "branch-cut off timing" mean the timing of freezing branch
> like when starting the release vote. It's because that the release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>>> Is it right?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I think I understand a bit better, though now I ask how this date is
different from the release date. Based on the HowToRelease instructions, we
set the release date to when the release vote passes. So, start of release
vote vs. end of release vote doesn't seem that different, and these dates
are still totally ordered.

For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.

I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.

Best,
Andrew

On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:

> > Andrew: I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Good point. Maybe I confuse you because of lack of explanation.
>
> I assume that "branch-cut off timing" mean the timing of freezing branch
> like when starting the release vote. It's because that the release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>>> Is it right?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I think I understand a bit better, though now I ask how this date is
different from the release date. Based on the HowToRelease instructions, we
set the release date to when the release vote passes. So, start of release
vote vs. end of release vote doesn't seem that different, and these dates
are still totally ordered.

For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.

I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.

Best,
Andrew

On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:

> > Andrew: I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Good point. Maybe I confuse you because of lack of explanation.
>
> I assume that "branch-cut off timing" mean the timing of freezing branch
> like when starting the release vote. It's because that the release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>>> Is it right?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

I think I understand a bit better, though now I ask how this date is
different from the release date. Based on the HowToRelease instructions, we
set the release date to when the release vote passes. So, start of release
vote vs. end of release vote doesn't seem that different, and these dates
are still totally ordered.

For the user in this scenario, she can upgrade from 2.7.3 to any later
2.7.c release (found easily since a.b.c releases are ordered), and when
jumping to a new minor or major version, any version released
chronologically after 2.7.3. This means you need to check the website, but
given that this is the way most enterprise software is versioned, I think
it'll be okay by users.

I think this problem is also pretty rare in practice, since users normally
upgrade to the highest maintenance release within a major/minor. Thus
they'll only hit this if their upgrade cycle is faster than it takes for a
change released in e.g. 2.6.x to then also be released in a 2.7.x.

Best,
Andrew

On Tue, Jul 26, 2016 at 11:13 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote:

> > Andrew: I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Good point. Maybe I confuse you because of lack of explanation.
>
> I assume that "branch-cut off timing" mean the timing of freezing branch
> like when starting the release vote. It's because that the release can
> be delayed after the release pass. Does it make sense to you?
>
> > Even if we have the branch-cut date in the version string, devs still
> need to be aware of other branches and backport appropriately.
>
> Yes, you're right. The good point of including date is that we can declare
> which version includes the latest changes. It helps users, not devs
> basically, to decide which version users will use: e.g. if
> 2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
> 2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
> against 2.7.3. Please let me know if I have some missing points.
>
> Thanks,
> - Tsuyoshi
>
> On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:
>
>> Thanks for replies Akira and Tsuyoshi, inline:
>>
>> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>>> Is it right?
>>
>>
>> Yes, correct.
>>
>>
>>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>>
>>> Pros:-) It's totally ordered. If we have a policy such as backporting
>>> to maintainance branches after the date, users can find that which
>>> version
>>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>>> fixes which is not included in 3.0.0-alpha1-20160724.
>>>
>>> Cons:-( A bit redundant.
>>>
>>> Could you elaborate on the problem this scheme addresses? We always want
>> our releases, when ordered chronologically, to incorporate all the known
>> relevant bug fixes. Even if we have the branch-cut date in the version
>> string, devs still need to be aware of other branches and backport
>> appropriately.
>>
>> Given that branch cuts and releases might not happen in the same order
>> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
>> for users. I bet many would assume it's the release date, like how Ubuntu
>> releases are numbered.
>>
>> Best,
>> Andrew
>>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> Andrew: I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Good point. Maybe I confuse you because of lack of explanation.

I assume that "branch-cut off timing" mean the timing of freezing branch
like when starting the release vote. It's because that the release can
be delayed after the release pass. Does it make sense to you?

> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.

Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:

> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>> Is it right?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> Andrew: I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Good point. Maybe I confuse you because of lack of explanation.

I assume that "branch-cut off timing" mean the timing of freezing branch
like when starting the release vote. It's because that the release can
be delayed after the release pass. Does it make sense to you?

> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.

Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:

> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>> Is it right?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> Andrew: I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Good point. Maybe I confuse you because of lack of explanation.

I assume that "branch-cut off timing" mean the timing of freezing branch
like when starting the release vote. It's because that the release can
be delayed after the release pass. Does it make sense to you?

> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.

Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:

> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>> Is it right?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

> Andrew: I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Good point. Maybe I confuse you because of lack of explanation.

I assume that "branch-cut off timing" mean the timing of freezing branch
like when starting the release vote. It's because that the release can
be delayed after the release pass. Does it make sense to you?

> Even if we have the branch-cut date in the version string, devs still
need to be aware of other branches and backport appropriately.

Yes, you're right. The good point of including date is that we can declare
which version includes the latest changes. It helps users, not devs
basically, to decide which version users will use: e.g. if
2.8.1-20160801 is released after 2.9.0-20160701 and a user uses
2.7.3-20160701, she can update their cluster 2.8.1, which include bug fixes
against 2.7.3. Please let me know if I have some missing points.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Andrew Wang <an...@cloudera.com> wrote:

> Thanks for replies Akira and Tsuyoshi, inline:
>
> Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
>> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
>> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
>> Is it right?
>
>
> Yes, correct.
>
>
>> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
>> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>>
>> Pros:-) It's totally ordered. If we have a policy such as backporting
>> to maintainance branches after the date, users can find that which version
>> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
>> fixes which is not included in 3.0.0-alpha1-20160724.
>>
>> Cons:-( A bit redundant.
>>
>> Could you elaborate on the problem this scheme addresses? We always want
> our releases, when ordered chronologically, to incorporate all the known
> relevant bug fixes. Even if we have the branch-cut date in the version
> string, devs still need to be aware of other branches and backport
> appropriately.
>
> Given that branch cuts and releases might not happen in the same order
> (e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
> for users. I bet many would assume it's the release date, like how Ubuntu
> releases are numbered.
>
> Best,
> Andrew
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks for replies Akira and Tsuyoshi, inline:

Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
> Is it right?


Yes, correct.


> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.

Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks for replies Akira and Tsuyoshi, inline:

Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
> Is it right?


Yes, correct.


> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.

Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks for replies Akira and Tsuyoshi, inline:

Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
> Is it right?


Yes, correct.


> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.

Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Best,
Andrew

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks for replies Akira and Tsuyoshi, inline:

Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we
> need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we
> don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira.
> Is it right?


Yes, correct.


> Tsuyoshi: My suggestion is adding the date when branch cut is done: like
> 3.0.0-alpha1-20160724, 2.8.0-20160730 or something.
>
> Pros:-) It's totally ordered. If we have a policy such as backporting
> to maintainance branches after the date, users can find that which version
> is cutting edge. In the example of above, 2.8.0-20160730 can include bug
> fixes which is not included in 3.0.0-alpha1-20160724.
>
> Cons:-( A bit redundant.
>
> Could you elaborate on the problem this scheme addresses? We always want
our releases, when ordered chronologically, to incorporate all the known
relevant bug fixes. Even if we have the branch-cut date in the version
string, devs still need to be aware of other branches and backport
appropriately.

Given that branch cuts and releases might not happen in the same order
(e.g. if 3.0.0-alpha1 precedes 2.8.0), I think this also would be confusing
for users. I bet many would assume it's the release date, like how Ubuntu
releases are numbered.

Best,
Andrew

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

Hi Vinod,

Thanks all guys for starting discussion!

My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.

Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.

Cons:-( A bit redundant.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:

> Forking the thread to make sure it attracts enough eye-balls. The earlier
> one was about 3.0.0 specifically and I don’t think enough people were
> watching that.
>
> I’ll try to summarize a bit.
>
> # Today’s state of release numbering and ordering:
>     So far, all the releases we have done, we have followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
>     The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
>     Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
>     Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
>     There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

Hi Vinod,

Thanks all guys for starting discussion!

My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.

Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.

Cons:-( A bit redundant.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:

> Forking the thread to make sure it attracts enough eye-balls. The earlier
> one was about 3.0.0 specifically and I don’t think enough people were
> watching that.
>
> I’ll try to summarize a bit.
>
> # Today’s state of release numbering and ordering:
>     So far, all the releases we have done, we have followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
>     The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
>     Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
>     Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
>     There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

Hi Vinod,

Thanks all guys for starting discussion!

My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.

Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.

Cons:-( A bit redundant.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:

> Forking the thread to make sure it attracts enough eye-balls. The earlier
> one was about 3.0.0 specifically and I don’t think enough people were
> watching that.
>
> I’ll try to summarize a bit.
>
> # Today’s state of release numbering and ordering:
>     So far, all the releases we have done, we have followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
>     The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
>     Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
>     Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
>     There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks Vinod for forking the thread. Let me try and summarize what Allen
and I talked about in the previous thread.

Currently, we've been marking JIRAs with fix versions of both 2.6.x and
2.7.x. IIUC, the chronological ordering between these two lines is actually
not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
entries. This makes sense from a user POV.

The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
Allen's historical perspective is that we've based each minor or major
release off of the previous minor release. So, 2.8.0 would be based off of
2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
be based off of 2.7.0. This also makes sense from a user POV; someone on a
2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
see what's changed.

Having looked at the changelogs of other enterprise software products, this
is pretty standard.

Perhaps restating the obvious, but:

* For a.b.c releases, the "c"s need to be released in order.
* For a.b.0 releases, the "b"s need to be released in order.
* For a.0.0 releases, it comes after a specific x.y.0 release.

Here's an attempt at encoding this policy as a set of rules for setting fix
versions (credit to Allen):

1) Set the fix version for all a.b.c versions, where c > 0.
2) For each major release line, set the lowest a.b.0 version.

The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
a.b.c versions, with alpha1 being the a.b.0 release.

As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
rule 1, and the last two fix versions come from rule 2.

I'm very eager to move this discussion forward, so feel free to reach out
on or off list if I can help with anything.

Best,
Andrew

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Tsuyoshi Ozawa <oz...@apache.org>]

Hi Vinod,

Thanks all guys for starting discussion!

My suggestion is adding the date when branch cut is done: like
3.0.0-alpha1-20160724, 2.8.0-20160730 or something.

Pros:-) It's totally ordered. If we have a policy such as backporting
to maintainance branches after the date, users can find that which version
is cutting edge. In the example of above, 2.8.0-20160730 can include bug
fixes which is not included in 3.0.0-alpha1-20160724.

Cons:-( A bit redundant.

Thanks,
- Tsuyoshi

On Wednesday, 27 July 2016, Vinod Kumar Vavilapalli <vinodkv@apache.org
<javascript:_e(%7B%7D,'cvml','vinodkv@apache.org');>> wrote:

> Forking the thread to make sure it attracts enough eye-balls. The earlier
> one was about 3.0.0 specifically and I don’t think enough people were
> watching that.
>
> I’ll try to summarize a bit.
>
> # Today’s state of release numbering and ordering:
>     So far, all the releases we have done, we have followed a simple
> timeline ordering. By this I mean that we always lined up releases one
> after another. Due to this, it was relatively simple to follow the causal
> ordering of releases, and we could answer ordering questions like “when was
> this patch first committed”.
>
>     The first time this started getting hairy was with parallel 2.6.x and
> 2.7.x releases. We managed the confusion by ordering them one after
> another: 2.7.1 -> 2.6.2 -> 2.6.3 -> 2.7.2 -> 2.6.4 -> 2.7.3. This worked
> okay with two concurrent releases.
>
>     Yes, by doing this, we could no longer answer questions by simply
> looking at the release numbers. But Sangjin / Junping / myself who did
> these 2.x releases ordered them one after another to avoid further
> confusion to developers and still retain the ability to just go back, look
> at the history and quickly answer the question of "what happened before and
> what happened after”. It wasn’t perfect, but we did what we did to keep it
> under control.
>
> # What’s coming
>     Obviously, with 2.8.0 and 3.0.0-alpha1 release trains starting, this
> confusion goes to a whole new level. We’ll have 2.6.x, 2.7.x, 2.8.x,
> 3.0.0.x (and 2.9.x if we chose to make one) and following the ordering
> becomes a nightmare. The related problems that were discussed in the
> original thread was about how we mark fix-versions for patches, and how we
> generate change-logs - the answers for both of these follow the solution to
> the root problem of concurrent releases.
>
> # Proposals?
>     There were some discussions about semantic versioning in the thread
> form which I forked this one from, but it’s not clear to me how semantic
> versioning supports concurrent release trains.
>
> IAC, it’s time we look at this afresh and if need be, make some new rules
> before we make more of these releases and make it that much harder to
> follow for everyone.
>
> Thanks
> +Vinod
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

[Andrew Wang <an...@cloudera.com>]

Thanks Vinod for forking the thread. Let me try and summarize what Allen
and I talked about in the previous thread.

Currently, we've been marking JIRAs with fix versions of both 2.6.x and
2.7.x. IIUC, the chronological ordering between these two lines is actually
not important. If you're on 2.6.1, you can see the new changes in 2.6.2 by
looking at what has the 2.6.2 fix version, and looking at the 2.6.2 CHANGES
entries. This makes sense from a user POV.

The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions.
Allen's historical perspective is that we've based each minor or major
release off of the previous minor release. So, 2.8.0 would be based off of
2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
be based off of 2.7.0. This also makes sense from a user POV; someone on a
2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes to
see what's changed.

Having looked at the changelogs of other enterprise software products, this
is pretty standard.

Perhaps restating the obvious, but:

* For a.b.c releases, the "c"s need to be released in order.
* For a.b.0 releases, the "b"s need to be released in order.
* For a.0.0 releases, it comes after a specific x.y.0 release.

Here's an attempt at encoding this policy as a set of rules for setting fix
versions (credit to Allen):

1) Set the fix version for all a.b.c versions, where c > 0.
2) For each major release line, set the lowest a.b.0 version.

The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
a.b.c versions, with alpha1 being the a.b.0 release.

As an example, if a JIRA was committed to branch-2.6, branch-2.7, branch-2,
branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5, 2.7.3,
2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
rule 1, and the last two fix versions come from rule 2.

I'm very eager to move this discussion forward, so feel free to reach out
on or off list if I can help with anything.

Best,
Andrew