hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <...@cloudera.com>
Subject Re: Release numbering for branch-2 releases
Date Fri, 01 Feb 2013 10:34:46 GMT
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

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.


On Thu, Jan 31, 2013 at 8:12 PM, Arun C Murthy <acm@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

View raw message