Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <57B212EA.7080605@gmail.com>
References: <57B212EA.7080605@gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Mon, 15 Aug 2016 12:21:36 -0700
Message-ID: <CA+RK=_BuEXLzXGAz+bL+uYaaDU80zkr7ZKuaBAW79aTOdKzaaQ@mail.gmail.com>
Subject: Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a114071126f9eed053a212637
archived-at: Mon, 15 Aug 2016 19:22:20 -0000

--001a114071126f9eed053a212637
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
=E2=80=8B
 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.

>
=E2=80=8B
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.

>
=E2=80=8B
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.


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 addition=
s
> to the Table interface [2] breaks the source compatibility of Phoenix wit=
h
> 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)
> =E2=80=8B=E2=80=8B
> 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 method=
s?
> 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 shou=
ld
> be defined in a non-public interface.
>
> 2)
> =E2=80=8B=E2=80=8B
> 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?
> =E2=80=8B=E2=80=8B
> 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
>


--=20
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--001a114071126f9eed053a212637--