hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSSION] Release process
Date Thu, 01 Apr 2010 16:33:17 GMT
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



      


Mime
View raw message