Thanks for the great reply, Andrew!
Andrew Purtell 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.
I agree. This is how I would've expected to see such an
non-public-facing method to have been added.
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 like the way this sounds. Would it make sense to try to work on
terminology to encapsulate this (after getting some more consensus that
this is desirable)?
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.
Yes, sorry, I could've been more specified. Source-compatibility on the
"public API" (defined presently by the Public audience annotation).
