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 Fri, 19 Aug 2016 22:57:01 GMT
On Fri, Aug 19, 2016 at 8:45 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> My bandwidth for tracking this thread has been limited. Have we concluded
> here that HBASE-16420 is the only fix we need before the next round of RCs?
>
>
Yes.

There is also the tightening of our compatibility guarantees on patch
versions done in doc via HBASE-16422.

>  I think we do, right? Isn't this exactly what the Bigtable Cloud folks
are doing? They would appear to have our blessing.

You have a point.

St.Ack



> On Tuesday, August 16, 2016, Josh Elser <josh.elser@gmail.com> wrote:
>
> > (top-post since I can't find a better place to respond to everyone who
> > chimed in here)
> >
> > Huge thanks, everyone! This was absolutely the best email thread (and
> JIRA
> > issue) I could've come back to after not keeping up with email for the
> day.
> >
> > Stack wrote:
> >
> >> On Tue, Aug 16, 2016 at 8:20 AM, Sean Busbey<busbey@apache.org>  wrote:
> >>
> >> On Tue, Aug 16, 2016 at 6:40 AM, Stack<stack@duboce.net>  wrote:
> >>>
> >>> On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang<ud1937@gmail.com>  wrote:
> >>>>
> >>>> I notice that HBASE-15645 is made up of several commits and revert in
> >>>>>
> >>>> git,
> >>>>
> >>>>> maybe it is more convenient to apply a new patch to remove the added
> >>>>> methods.
> >>>>>
> >>>>> Created a new issue (HBASE-16420
> >>>>> <https://issues.apache.org/jira/browse/HBASE-16420>) and waiting
for
> >>>>>
> >>>> the
> >>>
> >>>> result of pre-commit build. The patch only fix the incompatibility of
> >>>>>
> >>>> 1.1
> >>>
> >>>> and 1.2.  Do we need keep the compatibility between 1.x branches? If
> so
> >>>>>
> >>>> we
> >>>>
> >>>>> need also remove new methods from branch-1.3 and branch-1. And seems
> >>>>>
> >>>> some
> >>>
> >>>> other issues also added new methods to  non-Private  interface on
> >>>>> branch-1/1.3...
> >>>>>
> >>>>>
> >>>>> Patch looks good Phil. Thanks for putting it up.
> >>>>
> >>>> On your question, adding API in a manner that breaks compile is
> allowed
> >>>> going by our updated understanding.
> >>>>
> >>>>
> >>>> This should be "is not allowed" right?
> >>>
> >>>
> >>> Thanks Sean. Yes (Doc says right thing in HBASE-16422 patch)
> >>
> >>
> >>
> >> My reading of the consensus in the thread thus far is that adding
> methods
> >>> to IA.Public interfaces won't be possible in the 1.y line of releases
> due
> >>> to breaking source compatibility,
> >>>
> >>
> >>
> >>
> >> HBASE-16422 makes exclusion for patch release only. It does not preclude
> >> our breaking on minor versions.
> >>
> >>
> >>
> >> 1) starting to have a distinction between places we expect folks to just
> >>> consume API vs extend it?
> >>>
> >>> I used to be in favor of this, but Andrew's concern on bikeshedding has
> >>> me
> >>> reconsidering. Simpler rules seem better both to reduce the complexity
> of
> >>> communicating downstream and what the RMs have to keep in their heads
> >>> when
> >>> evaluating changes.
> >>>
> >>>
> >>> This and the below would be better on another thread I'd say Sean.
> >>
> >> Lets keep this thread for handling this little compat episode.
> >>
> >> Thanks,
> >> St.Ack
> >>
> >>
> >>
> >> 2) dropping our use of IS.Stable, IS.Evolving, etc.
> >>>
> >>> I've never found this distinction particularly useful since we aren't
> >>> very
> >>> consistent on it. The compat guide only specifies what it means for
> >>> "server
> >>> side APIs" without really defining what that means precisely, and we
> use
> >>> it
> >>> in client APIs as well. I think a reasonable reading of our current
> guide
> >>> could take the IS.Evolving designation to mean that the breaking change
> >>> to
> >>> Table was okay, but reading the comments on PHOENIX-3116 that
> >>> interpretation would clearly be surprising to at least one set of
> >>> downstream folks. (Plus none of the discussions I saw around this
> change
> >>> used this rationale, so its presence or lack thereof wouldn't have
> >>> changed
> >>> the conversation.)
> >>>
> >>>
> >>
>

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