You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Tom White <to...@cloudera.com> on 2013/02/01 11:34:46 UTC

Re: Release numbering for branch-2 releases

Possibly the reason for Stack's consternation is that this is a
Hadoop-specific versioning scheme, rather than a standard one like
Semantic Versioning (http://semver.org/) which is more widely
understood.

With that scheme we would have something like

  2.0.0-alpha, 2.0.0-alpha.1, 2.0.0-alpha.2, 2.0.0-alpha.3, 2.0.0-beta, 2.0.0

so that the alpha and beta tags all precede the 2.0.0 GA release,
which is the one that we make compatibility promises for.

Whereas Arun is proposing

  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0

and the casual observer might expect there to be a stable 2.0.1 (say)
on seeing the existence of 2.0.2-alpha.

The first three of these are already released, so I don't think we
could switch to the Semantic Versioning scheme at this stage. We could
for release 3 though.

Tom

On Thu, Jan 31, 2013 at 8:12 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
> Stack,
>
> On Jan 30, 2013, at 9:25 PM, Stack wrote:
>
>> I find the above opaque and written in a cryptic language that I might grok
>> if I spent a day or two running over cited issues trying to make some
>> distillation of the esotericia debated therein.  If you want feedback from
>> other than the cognescenti, I would suggest a better summation of what all
>> is involved.
>
>
> I apologize if there was too much technical details.
>
> The simplified version is that hadoop-2 isn't baked as it stands today, and is not viable to be supported by this community in a stable manner. In particular, it is due to the move to PB for HDFS protocols and the freshly minted YARN apis/protocols. As a result, we have been forced to make (incompatible) changes in every hadoop-2 release so far (2.0.0, 2.0.2 etc.). Since we released the previous bits we have found security issues, bugs and other issues which will cause long-term maintenance harm (details are in the HADOOP/HDFS/YARN jiras in the original email).
>
> My aim, as the RM, is to try nudge (nay, force) all contributors to spend time over the next couple of months focussing on fixing known issues and to look for other surprises - this way I hope to ensure we do not have further incompatible changes for downstream projects and we can support hadoop-2 for at least a couple of years. I hope this makes sense to you. I don't think turning around and calling these 3.x or 4.x makes things better since no amount of numbering lipstick will make the software better or viable for the long-term for both users and other projects. Worse, it will force HBase and other projects to deal with *even more* major Hadoop releases... which seems like a royal pita.
>
> I hope that clarifies things. Thanks Stack.
>
> Arun
>

Re: Release numbering for branch-2 releases

Posted by Andrew Purtell <ap...@apache.org>.
On Fri, Feb 1, 2013 at 2:34 AM, Tom White <to...@cloudera.com> wrote:

> Possibly the reason for Stack's consternation is that this is a
> Hadoop-specific versioning scheme, rather than a standard one like
> Semantic Versioning (http://semver.org/) which is more widely
> understood.


If I can offer an alternate and likely more accurate divination, I think
it's the idea of having API incompatibility (also protocol incompatibility)
with each 2.x release.

The preference I believe is for API incompatibilities /
protocol incompatibilities to trigger a major release increment rather than
be rolled into the 2.x branch. Alternatively, I think I can anticipate the
concerns, but have you considered introducing feature flags into the RPC
protocols? Protobuf is a tagged format, by design readers can deal with
missing or unexpected optional fields as long as sender and receiver can
negotiate a lingua franca (via feature flags, is one way).

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

> On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:
>
> > I think that using "-(alpha,beta)" tags on the release versions is a
> really
> > bad idea.
>
>
> Why? Can you please share some reasons?
>
>
We already had a means for denoting 'alpha' software -- release candidates
-- and 'beta'; early versions of a major release were installed with
trepidation by all but the clueless.

We also had a place for API changes and wire format revamps; they were done
in the next major version, not between point releases (caveat unintended
mess-ups).

The -alpha and -beta designations muddy hard-won understanding of what the
numbers mean.



> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
>

Not in hadoop though, not until these 2.0ings.



> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
Lets call it a snapshot instead because alpha is damaged (IMO).

Thanks Suresh,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Steve Loughran <st...@hortonworks.com>.
disclaimer, personal opinions only, I just can't be bothered to subscribe
with @apache.org right now.

On 4 February 2013 14:36, Todd Lipcon <to...@cloudera.com> wrote:

> - Quality/completeness: for example, missing docs, buggy UIs, difficult
> setup/install, etc
>

par for the course. Have you ever used Linux?


> - Safety: for example, potential bugs which may risk data loss
>

Anything that threatens data loss is a blocker, at least for data you care
about.


> - Stability: for example, potential bugs which may risk uptime
>

Less critical for most people, though it can cost lots of $$.


> - End-user API compatibility: will user-facing APIs change in this version?
> (affecting those who write MR jobs)
>



> - Framework-developer API compatibility: will YARN-internal APIs change in
> this version? (affecting those who write non-MR YARN frameworks)
>

Things aren't stable in 2.x there yet, YARN-117 is on my todo list, and
without that I consider it broken. the ASF haven't shipped a non-alpha
version of this -and I don't think anyone else has made any stability
claims either. That includes CDH 4.x, where YARN was a "play if you want"
feature. Or "wide-alpha", as I viewed it.


> - Binary compatibility: can I continue to use my application (or YARN)
> framework compiled against an old version with this version, without a
> recompile?
>

This is one thing Computer Science has never addressed fully. The whole of
the entire computing stack has to be considered "best-effort". If there is
one thing we can do here it is hooking up the entire set of OSS apps to the
nightly build, in a nice DAG including things like Cascading, Spring Data
&c, the way Apache Gump did to act as the regression test for Ant (before
Maven broke it)


> - Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
>

The presence of the 2.0.2 alpha stuff in the field complicates things. I
know you want upgrades, I'm sure others do too, but if that became an
approved version, there's the conflict with the "-1 version supported" rule
of wire compatibility -does it get changed?


> - Client-server wire compatibility: can I use old clients to talk to an
> upgraded cluster?
>

IMO we should move clients off the intra-cluster protocol, get them on
WebHDFS, the hcat job APIs, and have a hard split between public and
private. That includes distcp. As webhdfs is in 1.x+ that's the one to care
about.

>
> Depending on the user's expectations and needs, different factors above may
> be significantly more or less important. And different portions of the
> software may have different levels of stability in each of the areas. As
> I've mentioned in previous threads, my experiences supporting production
> Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
> while being "alpha" is significantly less prone to data loss bugs than 1.x
> in Hadoop.


I hope you are right -it's where everything is going.


> But, with some of the changes in the proposed 2.0.3-alpha, it
> wouldn't be wire-protocol-stable.
>
>
I don't know of anyone who wanted that, anyone who said "let's create chaos
and confusion", it was just a consequence of fixing things against an alpha
rlease.


> How can we best devise a scheme that explains the various factors above in
> a more detailed way than one big red warning sticker? What of the above
> factors does the community think would be implied by "GA?"
>

Let's see

 $ ant -version
> Apache Ant(TM) version 1.9.0alpha compiled on November 12 2012


Yes, Ant says "anything you build locally is an alpha release".

In that context,  it's no different from -SNAPSHOT except it's easier to
field bugreps against, because they are at least replicable; things
downstream can be updated to work with the alpha and test it.

I view beta as the transition to "feature complete: bugs and regression
only", with some triage, "patches that don't cause visible regressions"

Shipping is pretty much bugs only, with serious triage -only the widely
visible things happen after that. Critical integrity and performance merit
new updates.

Security fixes: out of band emergency updates. This is a good reason for
leaving security out of anything: a simpler support model. Unlike Oracle I
don't think security plugins should have side effects other than fix the
security hole.

Maven complicates things as you can't ever undeclare a release there -not
even for security reasons. Its why ops-managed RPM and deb updates are
preferred by ops groups for rolling out new binaries of any form to a pool
of boxes -at the expense of the application having control of its classpath
(ant has some special classpath setup to support OS-based installations,
BTW).

The way I've always viewed alpha and beta tags in apache projects is this:

   - you don't care about regressions of behaviour from features that
   weren't in the previous full release
   - the way you field all bug reports is say "is it gone from the latest
   release on that branch?" (*)

The big change in Hadoop is the filesystem: nobody want's to lose their
data, so you do need a story to help people migrate from alpha to next
alpha, beta to next beta. What I don't see being needed is

   1. Support for upgrades from, 2.x.x-alpha to anything 3.x-
   2. Freezing changes to the semantics of the user level APIs that weren't
   in the previous version.

I don't want to gratuitously break anything. It's just that releasing stuff
with the alpha tag doesn't mean "here is something that is stable and
supported by having its own branch maintained", it's "please play with this
and tell us what didn't work".

-Steve

Re: Release numbering for branch-2 releases

Posted by Steve Loughran <st...@hortonworks.com>.
disclaimer, personal opinions only, I just can't be bothered to subscribe
with @apache.org right now.

On 4 February 2013 14:36, Todd Lipcon <to...@cloudera.com> wrote:

> - Quality/completeness: for example, missing docs, buggy UIs, difficult
> setup/install, etc
>

par for the course. Have you ever used Linux?


> - Safety: for example, potential bugs which may risk data loss
>

Anything that threatens data loss is a blocker, at least for data you care
about.


> - Stability: for example, potential bugs which may risk uptime
>

Less critical for most people, though it can cost lots of $$.


> - End-user API compatibility: will user-facing APIs change in this version?
> (affecting those who write MR jobs)
>



> - Framework-developer API compatibility: will YARN-internal APIs change in
> this version? (affecting those who write non-MR YARN frameworks)
>

Things aren't stable in 2.x there yet, YARN-117 is on my todo list, and
without that I consider it broken. the ASF haven't shipped a non-alpha
version of this -and I don't think anyone else has made any stability
claims either. That includes CDH 4.x, where YARN was a "play if you want"
feature. Or "wide-alpha", as I viewed it.


> - Binary compatibility: can I continue to use my application (or YARN)
> framework compiled against an old version with this version, without a
> recompile?
>

This is one thing Computer Science has never addressed fully. The whole of
the entire computing stack has to be considered "best-effort". If there is
one thing we can do here it is hooking up the entire set of OSS apps to the
nightly build, in a nice DAG including things like Cascading, Spring Data
&c, the way Apache Gump did to act as the regression test for Ant (before
Maven broke it)


> - Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
>

The presence of the 2.0.2 alpha stuff in the field complicates things. I
know you want upgrades, I'm sure others do too, but if that became an
approved version, there's the conflict with the "-1 version supported" rule
of wire compatibility -does it get changed?


> - Client-server wire compatibility: can I use old clients to talk to an
> upgraded cluster?
>

IMO we should move clients off the intra-cluster protocol, get them on
WebHDFS, the hcat job APIs, and have a hard split between public and
private. That includes distcp. As webhdfs is in 1.x+ that's the one to care
about.

>
> Depending on the user's expectations and needs, different factors above may
> be significantly more or less important. And different portions of the
> software may have different levels of stability in each of the areas. As
> I've mentioned in previous threads, my experiences supporting production
> Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
> while being "alpha" is significantly less prone to data loss bugs than 1.x
> in Hadoop.


I hope you are right -it's where everything is going.


> But, with some of the changes in the proposed 2.0.3-alpha, it
> wouldn't be wire-protocol-stable.
>
>
I don't know of anyone who wanted that, anyone who said "let's create chaos
and confusion", it was just a consequence of fixing things against an alpha
rlease.


> How can we best devise a scheme that explains the various factors above in
> a more detailed way than one big red warning sticker? What of the above
> factors does the community think would be implied by "GA?"
>

Let's see

 $ ant -version
> Apache Ant(TM) version 1.9.0alpha compiled on November 12 2012


Yes, Ant says "anything you build locally is an alpha release".

In that context,  it's no different from -SNAPSHOT except it's easier to
field bugreps against, because they are at least replicable; things
downstream can be updated to work with the alpha and test it.

I view beta as the transition to "feature complete: bugs and regression
only", with some triage, "patches that don't cause visible regressions"

Shipping is pretty much bugs only, with serious triage -only the widely
visible things happen after that. Critical integrity and performance merit
new updates.

Security fixes: out of band emergency updates. This is a good reason for
leaving security out of anything: a simpler support model. Unlike Oracle I
don't think security plugins should have side effects other than fix the
security hole.

Maven complicates things as you can't ever undeclare a release there -not
even for security reasons. Its why ops-managed RPM and deb updates are
preferred by ops groups for rolling out new binaries of any form to a pool
of boxes -at the expense of the application having control of its classpath
(ant has some special classpath setup to support OS-based installations,
BTW).

The way I've always viewed alpha and beta tags in apache projects is this:

   - you don't care about regressions of behaviour from features that
   weren't in the previous full release
   - the way you field all bug reports is say "is it gone from the latest
   release on that branch?" (*)

The big change in Hadoop is the filesystem: nobody want's to lose their
data, so you do need a story to help people migrate from alpha to next
alpha, beta to next beta. What I don't see being needed is

   1. Support for upgrades from, 2.x.x-alpha to anything 3.x-
   2. Freezing changes to the semantics of the user level APIs that weren't
   in the previous version.

I don't want to gratuitously break anything. It's just that releasing stuff
with the alpha tag doesn't mean "here is something that is stable and
supported by having its own branch maintained", it's "please play with this
and tell us what didn't work".

-Steve

Re: Release numbering for branch-2 releases

Posted by Steve Loughran <st...@hortonworks.com>.
disclaimer, personal opinions only, I just can't be bothered to subscribe
with @apache.org right now.

On 4 February 2013 14:36, Todd Lipcon <to...@cloudera.com> wrote:

> - Quality/completeness: for example, missing docs, buggy UIs, difficult
> setup/install, etc
>

par for the course. Have you ever used Linux?


> - Safety: for example, potential bugs which may risk data loss
>

Anything that threatens data loss is a blocker, at least for data you care
about.


> - Stability: for example, potential bugs which may risk uptime
>

Less critical for most people, though it can cost lots of $$.


> - End-user API compatibility: will user-facing APIs change in this version?
> (affecting those who write MR jobs)
>



> - Framework-developer API compatibility: will YARN-internal APIs change in
> this version? (affecting those who write non-MR YARN frameworks)
>

Things aren't stable in 2.x there yet, YARN-117 is on my todo list, and
without that I consider it broken. the ASF haven't shipped a non-alpha
version of this -and I don't think anyone else has made any stability
claims either. That includes CDH 4.x, where YARN was a "play if you want"
feature. Or "wide-alpha", as I viewed it.


> - Binary compatibility: can I continue to use my application (or YARN)
> framework compiled against an old version with this version, without a
> recompile?
>

This is one thing Computer Science has never addressed fully. The whole of
the entire computing stack has to be considered "best-effort". If there is
one thing we can do here it is hooking up the entire set of OSS apps to the
nightly build, in a nice DAG including things like Cascading, Spring Data
&c, the way Apache Gump did to act as the regression test for Ant (before
Maven broke it)


> - Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
>

The presence of the 2.0.2 alpha stuff in the field complicates things. I
know you want upgrades, I'm sure others do too, but if that became an
approved version, there's the conflict with the "-1 version supported" rule
of wire compatibility -does it get changed?


> - Client-server wire compatibility: can I use old clients to talk to an
> upgraded cluster?
>

IMO we should move clients off the intra-cluster protocol, get them on
WebHDFS, the hcat job APIs, and have a hard split between public and
private. That includes distcp. As webhdfs is in 1.x+ that's the one to care
about.

>
> Depending on the user's expectations and needs, different factors above may
> be significantly more or less important. And different portions of the
> software may have different levels of stability in each of the areas. As
> I've mentioned in previous threads, my experiences supporting production
> Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
> while being "alpha" is significantly less prone to data loss bugs than 1.x
> in Hadoop.


I hope you are right -it's where everything is going.


> But, with some of the changes in the proposed 2.0.3-alpha, it
> wouldn't be wire-protocol-stable.
>
>
I don't know of anyone who wanted that, anyone who said "let's create chaos
and confusion", it was just a consequence of fixing things against an alpha
rlease.


> How can we best devise a scheme that explains the various factors above in
> a more detailed way than one big red warning sticker? What of the above
> factors does the community think would be implied by "GA?"
>

Let's see

 $ ant -version
> Apache Ant(TM) version 1.9.0alpha compiled on November 12 2012


Yes, Ant says "anything you build locally is an alpha release".

In that context,  it's no different from -SNAPSHOT except it's easier to
field bugreps against, because they are at least replicable; things
downstream can be updated to work with the alpha and test it.

I view beta as the transition to "feature complete: bugs and regression
only", with some triage, "patches that don't cause visible regressions"

Shipping is pretty much bugs only, with serious triage -only the widely
visible things happen after that. Critical integrity and performance merit
new updates.

Security fixes: out of band emergency updates. This is a good reason for
leaving security out of anything: a simpler support model. Unlike Oracle I
don't think security plugins should have side effects other than fix the
security hole.

Maven complicates things as you can't ever undeclare a release there -not
even for security reasons. Its why ops-managed RPM and deb updates are
preferred by ops groups for rolling out new binaries of any form to a pool
of boxes -at the expense of the application having control of its classpath
(ant has some special classpath setup to support OS-based installations,
BTW).

The way I've always viewed alpha and beta tags in apache projects is this:

   - you don't care about regressions of behaviour from features that
   weren't in the previous full release
   - the way you field all bug reports is say "is it gone from the latest
   release on that branch?" (*)

The big change in Hadoop is the filesystem: nobody want's to lose their
data, so you do need a story to help people migrate from alpha to next
alpha, beta to next beta. What I don't see being needed is

   1. Support for upgrades from, 2.x.x-alpha to anything 3.x-
   2. Freezing changes to the semantics of the user level APIs that weren't
   in the previous version.

I don't want to gratuitously break anything. It's just that releasing stuff
with the alpha tag doesn't mean "here is something that is stable and
supported by having its own branch maintained", it's "please play with this
and tell us what didn't work".

-Steve

Re: Release numbering for branch-2 releases

Posted by Todd Lipcon <to...@cloudera.com>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

>
> Why? Can you please share some reasons?
>
> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
My issue with the current scheme is that there is little definition as to
what alpha/beta/stable means. We're trying to boil down a complex issue
into a simple tag which doesn't well capture the various subtleties. For
example, different people may variously use the terms to describe:

- Quality/completeness: for example, missing docs, buggy UIs, difficult
setup/install, etc
- Safety: for example, potential bugs which may risk data loss
- Stability: for example, potential bugs which may risk uptime
- End-user API compatibility: will user-facing APIs change in this version?
(affecting those who write MR jobs)
- Framework-developer API compatibility: will YARN-internal APIs change in
this version? (affecting those who write non-MR YARN frameworks)
- Binary compatibility: can I continue to use my application (or YARN)
framework compiled against an old version with this version, without a
recompile?
- Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
- Client-server wire compatibility: can I use old clients to talk to an
upgraded cluster?

Depending on the user's expectations and needs, different factors above may
be significantly more or less important. And different portions of the
software may have different levels of stability in each of the areas. As
I've mentioned in previous threads, my experiences supporting production
Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
while being "alpha" is significantly less prone to data loss bugs than 1.x
in Hadoop. But, with some of the changes in the proposed 2.0.3-alpha, it
wouldn't be wire-protocol-stable.

How can we best devise a scheme that explains the various factors above in
a more detailed way than one big red warning sticker? What of the above
factors does the community think would be implied by "GA?"

Thanks
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Release numbering for branch-2 releases

Posted by Todd Lipcon <to...@cloudera.com>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

>
> Why? Can you please share some reasons?
>
> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
My issue with the current scheme is that there is little definition as to
what alpha/beta/stable means. We're trying to boil down a complex issue
into a simple tag which doesn't well capture the various subtleties. For
example, different people may variously use the terms to describe:

- Quality/completeness: for example, missing docs, buggy UIs, difficult
setup/install, etc
- Safety: for example, potential bugs which may risk data loss
- Stability: for example, potential bugs which may risk uptime
- End-user API compatibility: will user-facing APIs change in this version?
(affecting those who write MR jobs)
- Framework-developer API compatibility: will YARN-internal APIs change in
this version? (affecting those who write non-MR YARN frameworks)
- Binary compatibility: can I continue to use my application (or YARN)
framework compiled against an old version with this version, without a
recompile?
- Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
- Client-server wire compatibility: can I use old clients to talk to an
upgraded cluster?

Depending on the user's expectations and needs, different factors above may
be significantly more or less important. And different portions of the
software may have different levels of stability in each of the areas. As
I've mentioned in previous threads, my experiences supporting production
Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
while being "alpha" is significantly less prone to data loss bugs than 1.x
in Hadoop. But, with some of the changes in the proposed 2.0.3-alpha, it
wouldn't be wire-protocol-stable.

How can we best devise a scheme that explains the various factors above in
a more detailed way than one big red warning sticker? What of the above
factors does the community think would be implied by "GA?"

Thanks
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Release numbering for branch-2 releases

Posted by Todd Lipcon <to...@cloudera.com>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

>
> Why? Can you please share some reasons?
>
> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
My issue with the current scheme is that there is little definition as to
what alpha/beta/stable means. We're trying to boil down a complex issue
into a simple tag which doesn't well capture the various subtleties. For
example, different people may variously use the terms to describe:

- Quality/completeness: for example, missing docs, buggy UIs, difficult
setup/install, etc
- Safety: for example, potential bugs which may risk data loss
- Stability: for example, potential bugs which may risk uptime
- End-user API compatibility: will user-facing APIs change in this version?
(affecting those who write MR jobs)
- Framework-developer API compatibility: will YARN-internal APIs change in
this version? (affecting those who write non-MR YARN frameworks)
- Binary compatibility: can I continue to use my application (or YARN)
framework compiled against an old version with this version, without a
recompile?
- Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
- Client-server wire compatibility: can I use old clients to talk to an
upgraded cluster?

Depending on the user's expectations and needs, different factors above may
be significantly more or less important. And different portions of the
software may have different levels of stability in each of the areas. As
I've mentioned in previous threads, my experiences supporting production
Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
while being "alpha" is significantly less prone to data loss bugs than 1.x
in Hadoop. But, with some of the changes in the proposed 2.0.3-alpha, it
wouldn't be wire-protocol-stable.

How can we best devise a scheme that explains the various factors above in
a more detailed way than one big red warning sticker? What of the above
factors does the community think would be implied by "GA?"

Thanks
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

> On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:
>
> > I think that using "-(alpha,beta)" tags on the release versions is a
> really
> > bad idea.
>
>
> Why? Can you please share some reasons?
>
>
We already had a means for denoting 'alpha' software -- release candidates
-- and 'beta'; early versions of a major release were installed with
trepidation by all but the clueless.

We also had a place for API changes and wire format revamps; they were done
in the next major version, not between point releases (caveat unintended
mess-ups).

The -alpha and -beta designations muddy hard-won understanding of what the
numbers mean.



> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
>

Not in hadoop though, not until these 2.0ings.



> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
Lets call it a snapshot instead because alpha is damaged (IMO).

Thanks Suresh,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Todd Lipcon <to...@cloudera.com>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

>
> Why? Can you please share some reasons?
>
> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
My issue with the current scheme is that there is little definition as to
what alpha/beta/stable means. We're trying to boil down a complex issue
into a simple tag which doesn't well capture the various subtleties. For
example, different people may variously use the terms to describe:

- Quality/completeness: for example, missing docs, buggy UIs, difficult
setup/install, etc
- Safety: for example, potential bugs which may risk data loss
- Stability: for example, potential bugs which may risk uptime
- End-user API compatibility: will user-facing APIs change in this version?
(affecting those who write MR jobs)
- Framework-developer API compatibility: will YARN-internal APIs change in
this version? (affecting those who write non-MR YARN frameworks)
- Binary compatibility: can I continue to use my application (or YARN)
framework compiled against an old version with this version, without a
recompile?
- Intra-cluster wire compatibility: can I rolling-upgrade from A to B?
- Client-server wire compatibility: can I use old clients to talk to an
upgraded cluster?

Depending on the user's expectations and needs, different factors above may
be significantly more or less important. And different portions of the
software may have different levels of stability in each of the areas. As
I've mentioned in previous threads, my experiences supporting production
Hadoop 1.x and Hadoop 2.x HDFS clusters has led me to believe that 2.x,
while being "alpha" is significantly less prone to data loss bugs than 1.x
in Hadoop. But, with some of the changes in the proposed 2.0.3-alpha, it
wouldn't be wire-protocol-stable.

How can we best devise a scheme that explains the various factors above in
a more detailed way than one big red warning sticker? What of the above
factors does the community think would be implied by "GA?"

Thanks
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

> On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:
>
> > I think that using "-(alpha,beta)" tags on the release versions is a
> really
> > bad idea.
>
>
> Why? Can you please share some reasons?
>
>
We already had a means for denoting 'alpha' software -- release candidates
-- and 'beta'; early versions of a major release were installed with
trepidation by all but the clueless.

We also had a place for API changes and wire format revamps; they were done
in the next major version, not between point releases (caveat unintended
mess-ups).

The -alpha and -beta designations muddy hard-won understanding of what the
numbers mean.



> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
>

Not in hadoop though, not until these 2.0ings.



> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
Lets call it a snapshot instead because alpha is damaged (IMO).

Thanks Suresh,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas <su...@hortonworks.com>wrote:

> On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:
>
> > I think that using "-(alpha,beta)" tags on the release versions is a
> really
> > bad idea.
>
>
> Why? Can you please share some reasons?
>
>
We already had a means for denoting 'alpha' software -- release candidates
-- and 'beta'; early versions of a major release were installed with
trepidation by all but the clueless.

We also had a place for API changes and wire format revamps; they were done
in the next major version, not between point releases (caveat unintended
mess-ups).

The -alpha and -beta designations muddy hard-won understanding of what the
numbers mean.



> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
>

Not in hadoop though, not until these 2.0ings.



> Having an option to release alpha is good for releasing early and getting
> feedback from
> people who can try it out and at the same time warning other not so
> adventurous users on
> quality expectation.
>
>
Lets call it a snapshot instead because alpha is damaged (IMO).

Thanks Suresh,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Suresh Srinivas <su...@hortonworks.com>.
On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:

> I think that using "-(alpha,beta)" tags on the release versions is a really
> bad idea.


Why? Can you please share some reasons?

I actually think alpha and beta and stable/GA are much better way to set
the expectation
of the quality of a release. This has been practiced in software release
cycle for a long time.
Having an option to release alpha is good for releasing early and getting
feedback from
people who can try it out and at the same time warning other not so
adventurous users on
quality expectation.

Or do you propose any release that is not marked stable (currently 1.x) is
implicitly alpha/beta?

All releases should follow the strictly numeric
> (Major.Minor.Patch) pattern that we've used for all of the releases except
> the 2.0.x ones.
>
> -- Owen
>
>
> On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:
>
> > On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> > wrote:
> >
> > > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > > stable release? This way we just have one series (2.0.x) which is not
> > > suitable for general consumption.
> > >
> > >
> >
> > That contains the versioning damage to the 2.0.x set.  This is an
> > improvement over the original proposal where we let the versioning mayhem
> > run out 2.3.
> >
> > Thanks Arun,
> > St.Ack
> >
>



-- 
http://hortonworks.com/download/

Re: Release numbering for branch-2 releases

Posted by Suresh Srinivas <su...@hortonworks.com>.
On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:

> I think that using "-(alpha,beta)" tags on the release versions is a really
> bad idea.


Why? Can you please share some reasons?

I actually think alpha and beta and stable/GA are much better way to set
the expectation
of the quality of a release. This has been practiced in software release
cycle for a long time.
Having an option to release alpha is good for releasing early and getting
feedback from
people who can try it out and at the same time warning other not so
adventurous users on
quality expectation.

Or do you propose any release that is not marked stable (currently 1.x) is
implicitly alpha/beta?

All releases should follow the strictly numeric
> (Major.Minor.Patch) pattern that we've used for all of the releases except
> the 2.0.x ones.
>
> -- Owen
>
>
> On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:
>
> > On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> > wrote:
> >
> > > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > > stable release? This way we just have one series (2.0.x) which is not
> > > suitable for general consumption.
> > >
> > >
> >
> > That contains the versioning damage to the 2.0.x set.  This is an
> > improvement over the original proposal where we let the versioning mayhem
> > run out 2.3.
> >
> > Thanks Arun,
> > St.Ack
> >
>



-- 
http://hortonworks.com/download/

Re: Release numbering for branch-2 releases

Posted by Suresh Srinivas <su...@hortonworks.com>.
On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <om...@apache.org> wrote:

> I think that using "-(alpha,beta)" tags on the release versions is a really
> bad idea.


Why? Can you please share some reasons?

I actually think alpha and beta and stable/GA are much better way to set
the expectation
of the quality of a release. This has been practiced in software release
cycle for a long time.
Having an option to release alpha is good for releasing early and getting
feedback from
people who can try it out and at the same time warning other not so
adventurous users on
quality expectation.

Or do you propose any release that is not marked stable (currently 1.x) is
implicitly alpha/beta?

All releases should follow the strictly numeric
> (Major.Minor.Patch) pattern that we've used for all of the releases except
> the 2.0.x ones.
>
> -- Owen
>
>
> On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:
>
> > On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> > wrote:
> >
> > > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > > stable release? This way we just have one series (2.0.x) which is not
> > > suitable for general consumption.
> > >
> > >
> >
> > That contains the versioning damage to the 2.0.x set.  This is an
> > improvement over the original proposal where we let the versioning mayhem
> > run out 2.3.
> >
> > Thanks Arun,
> > St.Ack
> >
>



-- 
http://hortonworks.com/download/

Re: Release numbering for branch-2 releases

Posted by Owen O'Malley <om...@apache.org>.
I think that using "-(alpha,beta)" tags on the release versions is a really
bad idea. All releases should follow the strictly numeric
(Major.Minor.Patch) pattern that we've used for all of the releases except
the 2.0.x ones.

-- Owen


On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:

> On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> wrote:
>
> > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > stable release? This way we just have one series (2.0.x) which is not
> > suitable for general consumption.
> >
> >
>
> That contains the versioning damage to the 2.0.x set.  This is an
> improvement over the original proposal where we let the versioning mayhem
> run out 2.3.
>
> Thanks Arun,
> St.Ack
>

Re: Release numbering for branch-2 releases

Posted by Owen O'Malley <om...@apache.org>.
I think that using "-(alpha,beta)" tags on the release versions is a really
bad idea. All releases should follow the strictly numeric
(Major.Minor.Patch) pattern that we've used for all of the releases except
the 2.0.x ones.

-- Owen


On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:

> On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> wrote:
>
> > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > stable release? This way we just have one series (2.0.x) which is not
> > suitable for general consumption.
> >
> >
>
> That contains the versioning damage to the 2.0.x set.  This is an
> improvement over the original proposal where we let the versioning mayhem
> run out 2.3.
>
> Thanks Arun,
> St.Ack
>

Re: Release numbering for branch-2 releases

Posted by Owen O'Malley <om...@apache.org>.
I think that using "-(alpha,beta)" tags on the release versions is a really
bad idea. All releases should follow the strictly numeric
(Major.Minor.Patch) pattern that we've used for all of the releases except
the 2.0.x ones.

-- Owen


On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:

> On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> wrote:
>
> > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > stable release? This way we just have one series (2.0.x) which is not
> > suitable for general consumption.
> >
> >
>
> That contains the versioning damage to the 2.0.x set.  This is an
> improvement over the original proposal where we let the versioning mayhem
> run out 2.3.
>
> Thanks Arun,
> St.Ack
>

Re: Release numbering for branch-2 releases

Posted by Owen O'Malley <om...@apache.org>.
I think that using "-(alpha,beta)" tags on the release versions is a really
bad idea. All releases should follow the strictly numeric
(Major.Minor.Patch) pattern that we've used for all of the releases except
the 2.0.x ones.

-- Owen


On Mon, Feb 4, 2013 at 11:53 AM, Stack <st...@duboce.net> wrote:

> On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com>
> wrote:
>
> > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > stable release? This way we just have one series (2.0.x) which is not
> > suitable for general consumption.
> >
> >
>
> That contains the versioning damage to the 2.0.x set.  This is an
> improvement over the original proposal where we let the versioning mayhem
> run out 2.3.
>
> Thanks Arun,
> St.Ack
>

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
>

That contains the versioning damage to the 2.0.x set.  This is an
improvement over the original proposal where we let the versioning mayhem
run out 2.3.

Thanks Arun,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Suresh Srinivas <su...@hortonworks.com>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

>
> On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> > Whereas Arun is proposing
> >
> >  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> >
> > and the casual observer might expect there to be a stable 2.0.1 (say)
> > on seeing the existence of 2.0.2-alpha.
> >
> > The first three of these are already released, so I don't think we
> > could switch to the Semantic Versioning scheme at this stage. We could
> > for release 3 though.
> >
>
> I agree that would have been slightly better, unfortunately it's too late
> now - a new versioning scheme would be even more confusing!
>
> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
> I'm ok either way, but I want to just make a decision and move on to
> making the release asap, appreciate a quick resolution.
>

+1 for 2.0.3-alpha. 2.0.3-alpha has been the release number that we have
been working on for a while. I am surprised to see the feedback that it is
confusing.

Lets constructively move forward and make a decision and send the release
out quickly. Arun, my suggestion is to call for a release vote.

Regards,
Suresh




-- 
http://hortonworks.com/download/

Re: Release numbering for branch-2 releases

Posted by Suresh Srinivas <su...@hortonworks.com>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

>
> On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> > Whereas Arun is proposing
> >
> >  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> >
> > and the casual observer might expect there to be a stable 2.0.1 (say)
> > on seeing the existence of 2.0.2-alpha.
> >
> > The first three of these are already released, so I don't think we
> > could switch to the Semantic Versioning scheme at this stage. We could
> > for release 3 though.
> >
>
> I agree that would have been slightly better, unfortunately it's too late
> now - a new versioning scheme would be even more confusing!
>
> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
> I'm ok either way, but I want to just make a decision and move on to
> making the release asap, appreciate a quick resolution.
>

+1 for 2.0.3-alpha. 2.0.3-alpha has been the release number that we have
been working on for a while. I am surprised to see the feedback that it is
confusing.

Lets constructively move forward and make a decision and send the release
out quickly. Arun, my suggestion is to call for a release vote.

Regards,
Suresh




-- 
http://hortonworks.com/download/

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
>

That contains the versioning damage to the 2.0.x set.  This is an
improvement over the original proposal where we let the versioning mayhem
run out 2.3.

Thanks Arun,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Suresh Srinivas <su...@hortonworks.com>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

>
> On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> > Whereas Arun is proposing
> >
> >  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> >
> > and the casual observer might expect there to be a stable 2.0.1 (say)
> > on seeing the existence of 2.0.2-alpha.
> >
> > The first three of these are already released, so I don't think we
> > could switch to the Semantic Versioning scheme at this stage. We could
> > for release 3 though.
> >
>
> I agree that would have been slightly better, unfortunately it's too late
> now - a new versioning scheme would be even more confusing!
>
> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
> I'm ok either way, but I want to just make a decision and move on to
> making the release asap, appreciate a quick resolution.
>

+1 for 2.0.3-alpha. 2.0.3-alpha has been the release number that we have
been working on for a while. I am surprised to see the feedback that it is
confusing.

Lets constructively move forward and make a decision and send the release
out quickly. Arun, my suggestion is to call for a release vote.

Regards,
Suresh




-- 
http://hortonworks.com/download/

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
>

That contains the versioning damage to the 2.0.x set.  This is an
improvement over the original proposal where we let the versioning mayhem
run out 2.3.

Thanks Arun,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Stack <st...@duboce.net>.
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
>

That contains the versioning damage to the 2.0.x set.  This is an
improvement over the original proposal where we let the versioning mayhem
run out 2.3.

Thanks Arun,
St.Ack

Re: Release numbering for branch-2 releases

Posted by Arun C Murthy <ac...@hortonworks.com>.
On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> Whereas Arun is proposing
> 
>  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> 
> and the casual observer might expect there to be a stable 2.0.1 (say)
> on seeing the existence of 2.0.2-alpha.
> 
> The first three of these are already released, so I don't think we
> could switch to the Semantic Versioning scheme at this stage. We could
> for release 3 though.
> 

I agree that would have been slightly better, unfortunately it's too late now - a new versioning scheme would be even more confusing!

Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a stable release? This way we just have one series (2.0.x) which is not suitable for general consumption.

I'm ok either way, but I want to just make a decision and move on to making the release asap, appreciate a quick resolution.

thanks,
Arun

Re: Release numbering for branch-2 releases

Posted by Arun C Murthy <ac...@hortonworks.com>.
On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> Whereas Arun is proposing
> 
>  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> 
> and the casual observer might expect there to be a stable 2.0.1 (say)
> on seeing the existence of 2.0.2-alpha.
> 
> The first three of these are already released, so I don't think we
> could switch to the Semantic Versioning scheme at this stage. We could
> for release 3 though.
> 

I agree that would have been slightly better, unfortunately it's too late now - a new versioning scheme would be even more confusing!

Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a stable release? This way we just have one series (2.0.x) which is not suitable for general consumption.

I'm ok either way, but I want to just make a decision and move on to making the release asap, appreciate a quick resolution.

thanks,
Arun

Re: Release numbering for branch-2 releases

Posted by Arun C Murthy <ac...@hortonworks.com>.
On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> Whereas Arun is proposing
> 
>  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> 
> and the casual observer might expect there to be a stable 2.0.1 (say)
> on seeing the existence of 2.0.2-alpha.
> 
> The first three of these are already released, so I don't think we
> could switch to the Semantic Versioning scheme at this stage. We could
> for release 3 though.
> 

I agree that would have been slightly better, unfortunately it's too late now - a new versioning scheme would be even more confusing!

Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a stable release? This way we just have one series (2.0.x) which is not suitable for general consumption.

I'm ok either way, but I want to just make a decision and move on to making the release asap, appreciate a quick resolution.

thanks,
Arun

Re: Release numbering for branch-2 releases

Posted by Andrew Purtell <ap...@apache.org>.
On Fri, Feb 1, 2013 at 2:34 AM, Tom White <to...@cloudera.com> wrote:

> Possibly the reason for Stack's consternation is that this is a
> Hadoop-specific versioning scheme, rather than a standard one like
> Semantic Versioning (http://semver.org/) which is more widely
> understood.


If I can offer an alternate and likely more accurate divination, I think
it's the idea of having API incompatibility (also protocol incompatibility)
with each 2.x release.

The preference I believe is for API incompatibilities /
protocol incompatibilities to trigger a major release increment rather than
be rolled into the 2.x branch. Alternatively, I think I can anticipate the
concerns, but have you considered introducing feature flags into the RPC
protocols? Protobuf is a tagged format, by design readers can deal with
missing or unexpected optional fields as long as sender and receiver can
negotiate a lingua franca (via feature flags, is one way).

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Release numbering for branch-2 releases

Posted by Andrew Purtell <ap...@apache.org>.
On Fri, Feb 1, 2013 at 2:34 AM, Tom White <to...@cloudera.com> wrote:

> Possibly the reason for Stack's consternation is that this is a
> Hadoop-specific versioning scheme, rather than a standard one like
> Semantic Versioning (http://semver.org/) which is more widely
> understood.


If I can offer an alternate and likely more accurate divination, I think
it's the idea of having API incompatibility (also protocol incompatibility)
with each 2.x release.

The preference I believe is for API incompatibilities /
protocol incompatibilities to trigger a major release increment rather than
be rolled into the 2.x branch. Alternatively, I think I can anticipate the
concerns, but have you considered introducing feature flags into the RPC
protocols? Protobuf is a tagged format, by design readers can deal with
missing or unexpected optional fields as long as sender and receiver can
negotiate a lingua franca (via feature flags, is one way).

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Release numbering for branch-2 releases

Posted by Arun C Murthy <ac...@hortonworks.com>.
On Feb 1, 2013, at 2:34 AM, Tom White wrote:

> Possibly the reason for Stack's consternation is that this is a
> Hadoop-specific versioning scheme, rather than a standard one like
> Semantic Versioning (http://semver.org/) which is more widely
> understood.
> 
> With that scheme we would have something like
> 
>  2.0.0-alpha, 2.0.0-alpha.1, 2.0.0-alpha.2, 2.0.0-alpha.3, 2.0.0-beta, 2.0.0
> 
> so that the alpha and beta tags all precede the 2.0.0 GA release,
> which is the one that we make compatibility promises for.
> 
> Whereas Arun is proposing
> 
>  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> 

Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a stable release?

I'm ok either way, but I want to just make a decision and move on to making the release asap, appreciate a quick resolution.

thanks,
Arun

Re: Release numbering for branch-2 releases

Posted by Andrew Purtell <ap...@apache.org>.
On Fri, Feb 1, 2013 at 2:34 AM, Tom White <to...@cloudera.com> wrote:

> Possibly the reason for Stack's consternation is that this is a
> Hadoop-specific versioning scheme, rather than a standard one like
> Semantic Versioning (http://semver.org/) which is more widely
> understood.


If I can offer an alternate and likely more accurate divination, I think
it's the idea of having API incompatibility (also protocol incompatibility)
with each 2.x release.

The preference I believe is for API incompatibilities /
protocol incompatibilities to trigger a major release increment rather than
be rolled into the 2.x branch. Alternatively, I think I can anticipate the
concerns, but have you considered introducing feature flags into the RPC
protocols? Protobuf is a tagged format, by design readers can deal with
missing or unexpected optional fields as long as sender and receiver can
negotiate a lingua franca (via feature flags, is one way).

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Release numbering for branch-2 releases

Posted by Arun C Murthy <ac...@hortonworks.com>.
On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> Whereas Arun is proposing
> 
>  2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> 
> and the casual observer might expect there to be a stable 2.0.1 (say)
> on seeing the existence of 2.0.2-alpha.
> 
> The first three of these are already released, so I don't think we
> could switch to the Semantic Versioning scheme at this stage. We could
> for release 3 though.
> 

I agree that would have been slightly better, unfortunately it's too late now - a new versioning scheme would be even more confusing!

Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a stable release? This way we just have one series (2.0.x) which is not suitable for general consumption.

I'm ok either way, but I want to just make a decision and move on to making the release asap, appreciate a quick resolution.

thanks,
Arun