Our org (Trend Micro) will be using an internal build based on 0.20 for at least the rest of this year. It is, really, already "1.0" from our point of view, the first ASF Hadoop release officially adopted into our production environment. I hope other users of Hadoop will speak up on this thread to provide valuable feedback. I do hear informally that we are far from alone in this, but I have no idea if we are in a majority or not.
We could have adopted 0.21 -- and would have preferred to for the HDFS improvements needed by HBase to provide data durability -- but due to the length of time 0.21 has remained in an unreleased state that window has closed for us. We had internal milestones to meet. Instead we have adopted a modified 0.20. There are others like us who are basing production HBase systems on 0.20 + HDFS-200, and a couple of other HDFS patches of lesser consequence which have also been backported thanks to the kind assistance of Cloudera, Facebook, the HDFS devs, and others. I hope this user's perspective has been useful. Best regards, - Andy > From: Doug Cutting [...] > My latest proposal, a 1.0 branch based on 0.20, contains > two questions: > > 1. Should we make an Apache release that more closely > corresponds to what folks are using in production today (and > will be using for a while yet)? > > 2. If we're considering the 0.20 mapreduce and filesystem > APIs to be 1.0 APIs, and the new mapreduce and filesystem > APIs to be 2.0 APIs, shouldn't our release numbering reflect > that? Release numbers are fundamentally about > compatibility declarations. We could instead change > our compatibility rules to specifically mention certain > release numbers, but that feels the wrong way around. > Since we've not yet made a 0.21 release, we still have an > opportunity to interject a 1.0 release with the semantics > folks expect: its public APIs are stable. > > If there's support for this proposal, then I'd volunteer to > drive it. I won't bother to pursue this unless folks > think it is worthwhile, so, if you like it, please speak > up. While a release itself cannot be vetoed and only > requires a simple majority, we'll need to vote which patches > would be applied to a 1.0 branch, and those code-change > votes require consensus, so, vetos there would stop the > process. So please also speak up if you strongly > oppose this proposal. > > Doug
