hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix
Date Tue, 16 Aug 2016 19:25:38 GMT
> 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.

P
​lease prefer simpler rules, and checks and analyses that can be pushed
into tooling like RAT, the compat API checker, Yetus, and make_rc.sh. The
RM process has a fairly high cognitive load: Apache release requirements
(like dependency analysis and NOTICE and LICENSE spot-checks and audits),
metadata assembly (eg CHANGES.txt), the manual steps of the staging and
release workflow, test hygiene, integration testing, etc.
​

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?
>
> 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, but in the 2.y line we'll be able to use
> new Java 8 features to do so.
>
> Probably worth a different thread or two, but what do folks think about
>
> 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.
>
> 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.)
>



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