Also, the change to Table (HBASE-15645) went out in both 1.1.5 and 1.2.2. On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell <apurt...@apache.org> wrote:
> > > > I find the InterfaceAudience annotations on this really strange. How can > we have a Public audience Interface (o.a.h.h.c.Table) with Private methods? > > > I'm also not sure the Private annotations on the Table interface are that > useful. Any change to an interface renders it source incompatible, and > removal (or effective removal via signature change) of methods from an > interface introduces a binary incompatibility. I think the Private > annotations on methods of a Public interface imply we should refactor those > methods to a non-public interface. > > > > > Now that we've had quite a few releases in the "not-quite-SemVer" > compatibility guide, is there any interest in trying to make the > compatibility guarantees more stringent? > > I was looking at our compat guidelines (http://hbase.apache.org/book. > html#hbase.versioning) and think we could make a few refinements. > > We make several allowances for public interface changes that are binary > compatible but not source compatible in patch releases. I think we are only > taking into consideration callers but should also consider implementors of > public interfaces. Changing a public interface on a patch release renders > it source incompatible. Can we avoid doing that on *patch* releases, and > restrict this type of change to minors? > > Although we make allowances for public interface changes that are binary > compatible we also say "A minor upgrade requires no application/client code > modification." which could imply source compatibility even across minors, > which I believe is not the intent. > > We could add a source compatibility dimension for patch releases. > > > > > I would like to see us get to source-compatibility on patch releases, not > just binary compatibility > > You mean source compatibility for Public annotated interfaces only, right? > > In that case evaluating compliance would be easy: RMs would run the API > compat checker on a RC and if a patch release the number of binary and > source compat issues should both be zero. > > > On Mon, Aug 15, 2016 at 12:07 PM, Josh Elser <josh.el...@gmail.com> wrote: > >> Hi folks, >> >> I just noticed a ticket over in Phoenix [1] in which some method >> additions to the Table interface [2] breaks the source compatibility of >> Phoenix with HBase 1.2.2. >> >> My understanding of the current guidelines is that these are allowed as >> they do not invalidate binary compatibility of clients using the API. >> Personally, I am very hard-pressed to use the word "compatible" in a >> sentence describing this change that isn't sarcastic :) >> >> A couple of questions: >> >> 1) >> >> I find the InterfaceAudience annotations on this really strange. How can >> we have a Public audience Interface (o.a.h.h.c.Table) with Private methods? >> Is that just "how things are", or am I missing something? If this is not >> something that's meant to be public, I would think these new methods should >> be defined in a non-public interface. >> >> 2) >> >> Now that we've had quite a few releases in the "not-quite-SemVer" >> compatibility guide, is there any interest in trying to make the >> compatibility guarantees more stringent? >> >> I would like to see us get to source-compatibility on patch releases, not >> just binary compatibility. I am happy to try to help, but I know I don't >> have the time to devote to catch everything. >> >> 3) What do people think about changing this in a 1.2.3 with a quick >> turn-around? >> >> Thanks! >> >> - Josh >> >> [1] https://issues.apache.org/jira/browse/PHOENIX-3116 >> [2] https://issues.apache.org/jira/browse/HBASE-15645 >> > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
