hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Milind.Bhandar...@emc.com>
Subject Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Date Tue, 03 Apr 2012 21:37:17 GMT
Thanks ATM.

I guess the "*may*" emphasis confused me.

Just to get some more clarity:

What would be guideline for a new feature, such as
https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
compatibility for 1.x, but is not relevant to trunk, because the codebases
have completely diverged, so cannot be committed to trunk ?

- Milind

Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)

On 4/3/12 1:58 PM, "Aaron T. Myers" <atm@cloudera.com> wrote:

>Hi Milind,
>On Tue, Apr 3, 2012 at 11:27 AM, <Milind.Bhandarkar@emc.com> wrote:
>> Here you say:
>> > Essentially 'trunk' is where incompatible changes *may* be committed
>> >future). We should allow for that.
>What I believe Arun is alluding to here is that we expect for
>to be maintained for the lifetime of a major release branch.
>> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>> > We do expect 'new features' to make it to trunk before we can commit
>> >either branch-1 or branch-2.
>> Which one is it ?
>These two statements aren't mutually exclusive. We require that all new
>features go to trunk first so as to ensure that future releases are
>supersets of the functionality of previous releases, except in the case of
>explicit deprecation. Only once it's committed to trunk may it be
>back-ported to an earlier branch.
>> Do you expect that "new features" will always remain compatible ?
>Not necessarily, but only if a feature is compatible may it be back-ported
>to major release branches.
>Aaron T. Myers
>Software Engineer, Cloudera

View raw message