hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <steve.lough...@gmail.com>
Subject Re: [RESULT] Release plan for Hadoop 2.0.5
Date Wed, 15 May 2013 00:50:48 GMT
On 14 May 2013 11:52, Konstantin Shvachko <shv.hadoop@gmail.com> wrote:

> Sounds like you are having fun, Arun.
> 2.0.5 is explicitly in the subject line for this vote.
> No worries I'll fix that.
> You should stop assuming - it's in nobody interests - and start reading.
> --Konst

OK, I've been reading and have to say I'm confused.

  "If the next release has to be 2.0.5 I would like to make an alternative
proposal, which would include
  - stabilization of current 2.0.4
  - making all API changes to allow freezing them post 2.0.5
  And nothing else.

This means, if my interpretation is correct, that

1. there is a new fork off 2.0.4-alpha which has a name like 2.0.4-alpha-1
(as requested in JIRA), which will iterated until something ships, name
potentially 2.0.5

2. All "features" since 2.0.4-alpha are out, but API stabilisation is in.

3. There is some agreed on definition of API which may include -but is not
restricted to-: class signature, wire format, persistent data structures,
semantics as defined by tests cases, semantics as defined by some
formal/semi-formal specification, and the n-dimensional configuration
manifold defined by the set of parameters read from -config.xml.


#1: there is/will-soon-be a fork in SVN of 2.0.4-alpha which is going to be

#2: the RM and/or others have volunteered to pull in all the changes needed
to say "this is frozen and stable" and if you code against it then its
going to work for the duration of the 2.x line.

#3: but not changes considered "features".


1. What if there is a feature that is also an API change? How is the
definition of feature vs non-feature going to be taken up?

2. If there is already a change between 2.0.4-alpha and the forthcoming
2.0.5-beta which is visible at the API level then these will have to be
backport that so that its behaviour remains consistent over time.

3 If those changes in (2) are part of a feature by (1), then is someone
going to have to tease out the bits that will be declared "stable, API" and
not "feature, unstable"

Help me understand,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message