On Fri, Aug 19, 2016 at 8:45 AM, Nick Dimiduk <ndimi...@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.el...@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<bus...@apache.org> wrote: > >> > >> On Tue, Aug 16, 2016 at 6:40 AM, Stack<st...@duboce.net> wrote: > >>> > >>> On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang<ud1...@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.) > >>> > >>> > >> >
