hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Wed, 17 Aug 2016 04:31:42 GMT
(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
View raw message