hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Tue, 16 Aug 2016 03:55:18 GMT
> Are we extending this to all interfaces? Do we support folks implementing their own Connection?
Admin?

 This will bury us in weeds and bikeshedding. We can make a blanket rule about source compatibility
appropriately scoped to minors and/or patches without that drama. To wit:

> 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

We should take the opportunity to clarify the language of the compatibility guide. And if
the above is the policy then the change to Table is not allowed. 


> On Aug 15, 2016, at 8:26 PM, Sean Busbey <busbey@apache.org> wrote:
> 
> 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.

Mime
View raw message