hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Tue, 16 Aug 2016 00:15:13 GMT
On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell <apurtell@apache.org>
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 <josh.elser@gmail.com> 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)
>

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