Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of atm@cloudera.com designates
 209.85.212.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CBA08E09.325CC%Milind.Bhandarkar@emc.com>
References: <7294BB22-73B1-4D5D-97C2-D52CDD20E54B@hortonworks.com>
 <CBA08E09.325CC%Milind.Bhandarkar@emc.com>
From: "Aaron T. Myers" <atm@cloudera.com>
Date: Tue, 3 Apr 2012 13:58:38 -0700
Message-ID: 
 <CA+4052mjy-4BsgXZG236v6mfu_Q1ps5cCtwsy1ngca2Y7g3+8A@mail.gmail.com>
Subject: Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
To: hdfs-dev@hadoop.apache.org
Cc: common-dev@hadoop.apache.org, mapreduce-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=bcaec517ab02f8dc9404bccc93ae

--bcaec517ab02f8dc9404bccc93ae
Content-Type: text/plain; charset=ISO-8859-1

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 (in
> >future). We should allow for that.
>

What I believe Arun is alluding to here is that we expect for compatibility
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 to
> >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

--bcaec517ab02f8dc9404bccc93ae--