hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Tue, 16 Aug 2016 15:20:07 GMT
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?

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message