hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <...@cloudera.com>
Subject Re: [DISCUSSION] Release process
Date Wed, 31 Mar 2010 18:44:00 GMT
[Owen] > I think that we should change the rules so that the remaining
0.X releases are minor releases.


[Owen] > I'll volunteer to be release manager for a release branched
in November, which should be roughly 6 months after Tom's new 0.21

That would be great. Thanks, Owen!

[Doug] > I'm proposing we make a 1.0 release that tries to match what
folks are actually using in production and clarifies what APIs may be
relied upon to be stable going forward.

A pre-requisite to doing a 0.21 release is identifying the public API
that we intend to support going forward. To help enable this I intend
to backport the InterfaceAudience annotations to 0.20 (HADOOP-5073,
and associated JIRAs like HADOOP-6658) so we can run JDiff between the
public 0.20 API and 0.21. I'll also write some basic compatibility
tests to check that we can, for example, run MR programs on both
unchanged (MAPREDUCE-1637). Rather than doing a 1.0 release from 0.20,
perhaps it would be sufficient to run these tools could be run against
other Hadoop distributions to check compatibility.

[Konstantin] > I don't understand what is wrong with 0.21 released from 0.21?
[Konstantin] > - Making a new release from trunk will take long time
to stabilize.

The current 0.21 branch is 6 months behind trunk. Also, it's not clear
that it is backwards compatible with 0.20. I'm volunteering to create
a new 0.21 branch off trunk, then make a series of 0.21 releases,
which would get progressively more stable. This work would hopefully
act as a foundation for Owen's release in November.

Here's what I propose doing:

1. Create a new 0.21 branch from trunk on Friday 16 April.
2. Identify and fix blockers. Compatibility is the major blocker.
3. Cut a release candidate, test, vote - repeat until a release
candidate is agreed upon.


On Wed, Mar 31, 2010 at 10:13 AM, Konstantin Shvachko <shv@yahoo-inc.com> wrote:
> HDFS 0.20 does not have a reliable append.
> Also it is (was last time I looked) incompatible with the 0.21 append
> HDFS-256.
> That wouldn't be a problem if that was the only incompatibility. But it's
> not.
> If 1.0 is re-labeled or re-branched from 0.20 we will have to many
> incompatibilities
> going into further releases so that we will have to call all of them major
> ones
> for the foreseeable future.
> I don't understand what is wrong with 0.21 released from 0.21?
> - Making a new release from trunk will take long time to stabilize.
> - Branching out 0.20.x as 1.0 introduces too many incompatibilities.
> I would like to propose a straightforward release of 0.21 from current 0.21
> branch.
> --Konstantin
> On 3/31/2010 9:04 AM, Doug Cutting wrote:
>> Owen O'Malley wrote:
>>> It is tempting and I think that 0.20 is *really* our 1.0, but I think
>>> re-labeling a release a year after it came out would be confusing.
>> I wasn't proposing just a re-labeling. I was proposing a new release,
>> branched from 0.20 rather than trunk. We'd introduce some changes, after
>> voting on each of course. Candidates are MAPREDUCE-1623 and
>> MAPREDUCE-1650, to better clarify what's intended to be supported in
>> 1.0, and HDFS-200, to make append reliable.
>> Since we have not yet made a 0.21 release, this numbering would be
>> consistent. It also naturally permits further 1.x releases that add
>> features, like security.
>> Doug

View raw message