Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce >> mail # dev >> Release numbering for branch-2 releases


Copy link to this message
-
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 <[EMAIL PROTECTED]> 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
>