hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Fri, 19 Aug 2016 15:51:18 GMT
> Are we extending this to all interfaces? Do we support folks
implementing their own Connection? Admin?

I think we do, right? Isn't this exactly what the Bigtable Cloud folks are
doing? They would appear to have our blessing.

On Friday, August 19, 2016, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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.)
>>>>
>>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message