hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Carey <sc...@richrelevance.com>
Subject Re: [DISCUSS] Apache Hadoop 1.0?
Date Thu, 17 Nov 2011 02:06:18 GMT

On 11/16/11 3:51 PM, "Nathan Roberts" <nroberts@yahoo-inc.com> wrote:

>On 11/16/11 4:43 PM, "Arun C Murthy" <acm@hortonworks.com> wrote:
>> I propose we adopt the convention that a new major version should be a
>>superset of the previous major version, features-wise.
>Just so I'm clear. This is only guaranteed at the time the new major
>version is started. A day later a previous major line may merge a feature
>from trunk and then it's no longer the case that 2.x.y is a superset. If
>that's the case I'm not sure of the value of the convention. We could say
>that new major versions always start from trunk, but that doesn't have
>meaning outside of the developer community.

I don't think in general one can say that major versions are a superset of
previous major versions.  Then you would need to have a SuperMajor version
number for the (rare) times that this was broken.
In other words, the major version number really can't have any
Perhaps however, one can say that minor versions are supersets of prior
minor version if one were to define 'superset'.

Its going to be hard to claim that the 0.23 branch is a superset of 0.22
-- After all, there is no JobTracker and all sorts of stuff has been
removed or replaced with something else.  Whether that defines a superset
or not gets into a lot of semantics of what we mean by 'superset'.

Perhaps like 'feature' or 'bug fix', it is best not to get into the
semantics of defining what we mean by 'superset' and rather define version
number meaning only in terms of compatibility classifications.  Especially
since the compatibility classification has implications for all of these
other things  -- and IMO more clearly useful ones.  For example, consider
that a "bug fix" may break wire compatibility, that a tiny harmless change
can be considered a "new feature", or that replacing a single link in a UI
could be considered breaking a "superset" rule.

>On Nov 16, 2011, at 3:02 PM, Doug Cutting wrote:
>> Another definition is that a major release permits incompatible changes,
>> either in APIs, wire-formats, on-disk formats, etc.
>Are our wire formats stable enough in all release lines that we're ready
>to live by this? It would mean the 1.x.y line could not change a wire
>format without a bump to the major number, which would obviously cause
>issues. Even in the 23.x line I thought there were still some wire
>compatibility changes pending which would mean we'd quickly be moving to
>a 4.x line.

View raw message