hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Mon, 15 Aug 2016 21:47:03 GMT
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).

View raw message