On Tue, Aug 16, 2016 at 6:40 AM, Stack <[email protected]> wrote: > On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang <[email protected]> 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?
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, but in the 2.y line we'll be able to use new Java 8 features to do so. Probably worth a different thread or two, but what do folks think about 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. 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.)
