hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Tue, 16 Aug 2016 03:26:38 GMT
Thanks for bringing this up Josh!

On Mon, Aug 15, 2016 at 2:21 PM, Andrew Purtell <apurtell@apache.org> 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.
> >

Generally, we use more restricted audience annotations on members within a
given API to show where there are limits on our support that we can't
express in Java access modifiers. I think it's important for us to keep
this around so that we can avoid a proliferation of "FooUtil" and other
classes that exist just to make a Public/Private distinction. (I recognize
we have several of these but I was hoping we'd move in the direction of
fewer over time.)

I agree that in the case of interfaces it's problematic, since we have no
way to distinguish between "should be consumed" and "can be extended".
Perhaps we should make sure we have abstract classes instead of interfaces?
We could also add an annotation to make the consumed/extended distinction;
I've seen it come up a few times in other users of audience annotations.

> ​
> 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?
Are we extending this to all interfaces? Do we support folks implementing
their own Connection? Admin?

> 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.
So when I read the existing guides, what I see is that we're supposed to be
_source_ compatible on minor and patch releases, but binary compatible only
on patch releases. I think we discussed this a year or two ago, and IIRC
the reasoning was that since we maintain wire compatibility on minor and
patch releases, those who need to ignore a given set of binary incompatible
changes can just make use of the older library.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message