On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell <[email protected]> wrote:
> ... > 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. > > Makes sense Andrew. > > > > 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. > > Can we have yetus report on compat? I'd be up for helping get out a 1.2.3 (and a fix in 1.1.6) to address this compat hiccup especially given I was party to the change. I +1'd and committed the patch thinking addition of methods ok not thinking of the Table implementors. St.Ack > > On Mon, Aug 15, 2016 at 12:07 PM, Josh Elser <[email protected]> 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) >
