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