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