On Tue, Aug 16, 2016 at 8:20 AM, Sean Busbey <[email protected]> wrote:
> 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? > > 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.) >
