I have HBASE-16158 open to run check_compatibility.sh as part of our Yetus personality, I just got sidetracked by other work. Let me try to get something up by week's end.
-Dima On Mon, Aug 15, 2016 at 5:15 PM, Stack <[email protected]> wrote: > 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) > > > -- -Dima
