hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: Naming of Hadoop releases
Date Mon, 19 Mar 2012 22:38:28 GMT
On Mon, Mar 19, 2012 at 2:56 PM, Doug Cutting <cutting@apache.org> wrote:
> On 03/19/2012 02:47 PM, Arun C Murthy wrote:
>> This is against the Apache Hadoop release policy on major releases i.e. only features
deprecated for at least one release can be removed.
> In many case the reason this happened was that features were backported
> from trunk to 0.20 but not to 0.22.  In other words, its no fault of the
> folks who were working on branch 0.22.

I agree that it's no fault of the folks on 0.22.

>  So a related policy we might add
> to prevent such situations in the future might be that if you backport
> something from branch n to n-2 then you ought to also be required to
> backport it to branch n-1 and in general to all intervening branches.
> Does that seem sensible?

-1 on this requirement. Otherwise the cost of backporting something to
the stable line becomes really high, and we'll end up with
distributors just maintaining their own branches outside of Apache
(the state we were in with 0.20.x).

On the other hand, it does suck for users if they update from "1.x" to
"2.x" and they end up losing some bug fixes or features they
previously were running.

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.

Todd Lipcon
Software Engineer, Cloudera

View raw message