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> 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.) >>> >>> >>
