hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Carey <sc...@richrelevance.com>
Subject Re: Naming of Hadoop releases
Date Tue, 20 Mar 2012 18:21:08 GMT

On 3/19/12 3:38 PM, "Todd Lipcon" <todd@cloudera.com> wrote:
>>  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.

Users should not expect upgrades from one major version to another to be
trivial.  Documentation on feature differences and upgrade paths are
expected for major changes.
It would be really bad if you went from 1.0.1 to 1.0.2 and lost security.
Upgrading from 1.x to 2.x and gaining/losing features is a non-issue IMO.

A major version bump indicates major differences.  These will necessarily
mean dropping of old features over time.  Rules on major versions about
feature supersets or deprecate-first requirements end up being meaningless
over time (the former is not tenable, the latter easy to circumvent with a
short lived release).

It is saner to define what a major/minor/patch version meanings are for
releases by default and then for each specific release note if that
differs from the norm.

I propse:
* Major version increment:  significant API or backwards compatibility
affecting changes may be present.  See documentation for details.
* Minor version increment:  API changes likely.  New features typically
added.  Removed features documented.  Expectation of backwards
compatibility unless otherwise noted in the release.
* Patch version increment:  fully backwards compatible in API and
Operation.  Bug fixes and minor features that

I don't see any logic at all as to why 0.22 can't be 2.0 -- a major
version number change indicates major differences.  If one of those
differences is that security is not present, so what?  There cannot be any
restriction on what can change across major number bumps.  _Any
conceivable restriction_ to what can change in a major release is flawed.
At some point, that feature or API may need to expire.

View raw message