hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris K Wensel <ch...@wensel.net>
Subject Re: [DISCUSSION] Release process
Date Thu, 01 Apr 2010 17:11:15 GMT
are we saying we will de-deprecate the stable APIs in .20, or make the new APIs introduced
in .20 stable?

+1 on removing the deprecations on the stable APIs.

On Mar 31, 2010, at 2:19 PM, Doug Cutting wrote:

> Konstantin Shvachko wrote:
>> I would like to propose a straightforward release of 0.21 from current 0.21 branch.
> That could be done too.  Tom's volunteered to drive a release from trunk in a few weeks.
 Owen's volunteered to drive another release from trunk in about six months.  Would you like
to volunteer to drive a release from the current 0.21 branch?
> 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
> Doug

Chris K Wensel

View raw message