hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Release numbering for branch-2 releases
Date Fri, 01 Feb 2013 20:35:17 GMT
On Thu, Jan 31, 2013 at 12:12 PM, Arun C Murthy <acm@hortonworks.com> wrote:

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

Tom above puts his finger on the problem I am having.  It seems that the
'hadoop versioning' is arbitrary, flaunts convention, and on top of that is
without a discernible pattern (2.0.0 is actually going to be 2.3.0?).  It
is also tantalizing as it holds out the promise of a 2.0.0 or a 2.1.0,
etc., but seemingly these will never ship.

Above you call 3.x and 4.x 'numbering liipstick' -- nice one! -- but to
this 'casual observer', IMO, it would be more calling a spade a spade; i.e.
3.x.x, a major version change, has API and possibly wire protocol changes
in it.

Thank you for taking the time to dumb it all down for me Arun,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message