Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <57B3E8AE.4090706@gmail.com>
References: <57B212EA.7080605@gmail.com> <CA+RK=_BuEXLzXGAz+bL+uYaaDU80zkr7ZKuaBAW79aTOdKzaaQ@mail.gmail.com>
 <CAN5cbe741_Cep2K3QvBYaCA572NwNrzL+1px+f-CqXm3FA2SRQ@mail.gmail.com>
 <C58A274E-1771-4EF3-8178-C3DAD87C0A34@gmail.com> <CAN5cbe76ro7FfO1-WTmnMit6j1W_xGg=tCQfmuSozxt8=vs9og@mail.gmail.com>
 <CAN5cbe7nc2iCeSATBv0sK+81ZdVTajh1DLmOv-op43MJb5PnEQ@mail.gmail.com>
 <CAAAYAnOzc55mbuVckVZeZ3PUU0zJdfp=YaS=kwtK=CsUzrN4Wg@mail.gmail.com>
 <CA+7gEcjvHY5zocKP9XPUdR25bWveO5-p5bP8dYccqFnr1ht_Bw@mail.gmail.com>
 <CA+7gEcjC3EfcedkrN8iOr8zYD488WgVddGUmiKHXJidWUdREQA@mail.gmail.com>
 <CADcMMgHcDb0uh0FgxwqgVSQGgGBTJB4CZU5vtMPQBvaBVsyL0Q@mail.gmail.com>
 <CAN5cbe647x3o+riFpAtTLECV8DPfOv0V3hQBhhAXPjdUJ4cE9w@mail.gmail.com>
 <CADcMMgG2SY2tyfW5NCMBcA=cTj-GkUKBRJEvWeGOWG3VSqYuGw@mail.gmail.com> <57B3E8AE.4090706@gmail.com>
From: Nick Dimiduk <ndimiduk@gmail.com>
Date: Fri, 19 Aug 2016 08:45:48 -0700
Message-ID: <CANZa=GsU3b8Jq=fVbt0pPV-COH0xMjAp-yy4_hc6v7BZcpFYQg@mail.gmail.com>
Subject: Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=047d7b8743f6bacb48053a6e97bb
archived-at: Fri, 19 Aug 2016 15:46:03 -0000

--047d7b8743f6bacb48053a6e97bb
Content-Type: text/plain; charset=UTF-8

My bandwidth for tracking this thread has been limited. Have we concluded
here that HBASE-16420 is the only fix we need before the next round of RCs?

On Tuesday, August 16, 2016, Josh Elser <josh.elser@gmail.com> wrote:

> (top-post since I can't find a better place to respond to everyone who
> chimed in here)
>
> Huge thanks, everyone! This was absolutely the best email thread (and JIRA
> issue) I could've come back to after not keeping up with email for the day.
>
> Stack wrote:
>
>> On Tue, Aug 16, 2016 at 8:20 AM, Sean Busbey<busbey@apache.org>  wrote:
>>
>> On Tue, Aug 16, 2016 at 6:40 AM, Stack<stack@duboce.net>  wrote:
>>>
>>> On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang<ud1937@gmail.com>  wrote:
>>>>
>>>> I notice that HBASE-15645 is made up of several commits and revert in
>>>>>
>>>> git,
>>>>
>>>>> maybe it is more convenient to apply a new patch to remove the added
>>>>> methods.
>>>>>
>>>>> Created a new issue (HBASE-16420
>>>>> <https://issues.apache.org/jira/browse/HBASE-16420>) and waiting for
>>>>>
>>>> the
>>>
>>>> result of pre-commit build. The patch only fix the incompatibility of
>>>>>
>>>> 1.1
>>>
>>>> and 1.2.  Do we need keep the compatibility between 1.x branches? If so
>>>>>
>>>> we
>>>>
>>>>> need also remove new methods from branch-1.3 and branch-1. And seems
>>>>>
>>>> some
>>>
>>>> other issues also added new methods to  non-Private  interface on
>>>>> branch-1/1.3...
>>>>>
>>>>>
>>>>> Patch looks good Phil. Thanks for putting it up.
>>>>
>>>> On your question, adding API in a manner that breaks compile is allowed
>>>> going by our updated understanding.
>>>>
>>>>
>>>> This should be "is not allowed" right?
>>>
>>>
>>> Thanks Sean. Yes (Doc says right thing in HBASE-16422 patch)
>>
>>
>>
>> My reading of the consensus in the thread thus far is that adding methods
>>> to IA.Public interfaces won't be possible in the 1.y line of releases due
>>> to breaking source compatibility,
>>>
>>
>>
>>
>> HBASE-16422 makes exclusion for patch release only. It does not preclude
>> our breaking on minor versions.
>>
>>
>>
>> 1) starting to have a distinction between places we expect folks to just
>>> consume API vs extend it?
>>>
>>> I used to be in favor of this, but Andrew's concern on bikeshedding has
>>> me
>>> reconsidering. Simpler rules seem better both to reduce the complexity of
>>> communicating downstream and what the RMs have to keep in their heads
>>> when
>>> evaluating changes.
>>>
>>>
>>> This and the below would be better on another thread I'd say Sean.
>>
>> Lets keep this thread for handling this little compat episode.
>>
>> Thanks,
>> St.Ack
>>
>>
>>
>> 2) dropping our use of IS.Stable, IS.Evolving, etc.
>>>
>>> I've never found this distinction particularly useful since we aren't
>>> very
>>> consistent on it. The compat guide only specifies what it means for
>>> "server
>>> side APIs" without really defining what that means precisely, and we use
>>> it
>>> in client APIs as well. I think a reasonable reading of our current guide
>>> could take the IS.Evolving designation to mean that the breaking change
>>> to
>>> Table was okay, but reading the comments on PHOENIX-3116 that
>>> interpretation would clearly be surprising to at least one set of
>>> downstream folks. (Plus none of the discussions I saw around this change
>>> used this rationale, so its presence or lack thereof wouldn't have
>>> changed
>>> the conversation.)
>>>
>>>
>>

--047d7b8743f6bacb48053a6e97bb--