hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: [DISCUSSION] Release process
Date Wed, 31 Mar 2010 21:19:40 GMT
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 proposal.

Doug

Mime
View raw message