hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: Naming of Hadoop releases
Date Mon, 19 Mar 2012 23:18:49 GMT
On 03/19/2012 03:38 PM, Todd Lipcon wrote:
> Unfortunately, I don't have a better solution in mind that resolves
> the above problems - I just don't think it's tenable to combine a
> policy like "anyone may make a release branch off trunk and claim a
> major version number" with another policy like "you have to port a fix
> to all intermediate versions in order to port a fix to any of them".
> If a group of committers wants to make a release branch, then the
> maintenance of that branch should be up to them.

I don't think it's the case that anyone can create a new major version
number.  Creation of new release branches should be an activity of the
PMC, not individuals.  As such, the majority of the PMC implicitly or
explicitly approves such branches and the PMC must responsibly deal with
the ensuing results.  We should not operate as a fragmented community
creating a fragmented, overlapping set of products.

As I recall, when the 0.22 release branch was created it was intended by
the PMC to be a release branch that followed 0.20 and preceded 0.23.
Since then we as a PMC have acted inconsistently and now must deal with
the consequences.

We've already made an exception to our policies in releasing 0.20.20x
and 0.22 that regresses from it in some areas.  We now need to decide
whether we want to continue that exception by renaming 0.22 to 2.0 or
not.  It does not look like we'll reach consensus on this.  That's
unfortunate, but we still need to answer it.

We also should decide whether we want to permit ourselves to get in this
pinch again.  I think it's avoidable if in the future we only make
releases that are consistent with our other policies.  Backports should
be easier for intervening releases.  We might reasonably grandfather
0.22 as skippable for backports as it's too late to fix that now.


View raw message