Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of eli@cloudera.com designates
 209.85.216.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALwhT95Z3DXL6KOmK3pfyC26pur-P8tRO1TNDdC-5UCc2o_beQ@mail.gmail.com>
References: 
 <CALwhT95Z3DXL6KOmK3pfyC26pur-P8tRO1TNDdC-5UCc2o_beQ@mail.gmail.com>
Date: Tue, 7 Jan 2014 17:05:31 -0800
Message-ID: 
 <CAPn_vTtt1D9hVA8WeVfm6m2nQiXs-bUoHcZ3JVyqHvqX95uW1g@mail.gmail.com>
Subject: Re: When to mark a JIRA incompatible?
From: Eli Collins <eli@cloudera.com>
To: "yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=047d7b60457eef301f04ef6b1687

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

When it's incompatible with a previous release. You can change a new public
API several times in an incompatible way before you release it. Not yarn
specific btw, same rules for all of Hadoop.

On Tuesday, January 7, 2014, Karthik Kambatla wrote:

> Hey devs,
>
> Was just wondering if the Incompatible Change flag on JIRA is to be checked
> if the patch is incompatible with an existing release or even if it is
> incompatible with contents of branch-2?
>
> For instance, YARN-1568 fixes something introduced by YARN-1029 that was
> only committed yesterday, but in an incompatible way.
>
> Thanks
> Karthik
>

--047d7b60457eef301f04ef6b1687--