> 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 <ndimi...@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.el...@gmail.com > <javascript:_e(%7B%7D,'cvml','josh.el...@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<bus...@apache.org> wrote: >>> >>> On Tue, Aug 16, 2016 at 6:40 AM, Stack<st...@duboce.net> wrote: >>>> >>>> On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang<ud1...@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.) >>>> >>>> >>>
