hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dima Spivak <dspi...@cloudera.com>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Tue, 16 Aug 2016 00:21:18 GMT
I have HBASE-16158 open to run check_compatibility.sh as part of our Yetus
personality, I just got sidetracked by other work. Let me try to get
something up by week's end.

-Dima

On Mon, Aug 15, 2016 at 5:15 PM, Stack <stack@duboce.net> wrote:

> 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)
> >
>



-- 
-Dima

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