Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Fri, Aug 19, 2016 at 8:45 AM, Nick Dimiduk 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

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

> Are we extending this to all interfaces? Do we support folks implementing their own Connection? Admin? I think we do, right? Isn't this exactly what the Bigtable Cloud folks are doing? They would appear to have our blessing. On Friday, August 19, 2016, Nick Dimiduk wrote:

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

(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

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

> 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

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Tue, Aug 16, 2016 at 8:20 AM, Sean Busbey wrote: > On Tue, Aug 16, 2016 at 6:40 AM, Stack wrote: > > > On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang wrote: > > > > > I notice that HBASE-15645 is made up of several commits and revert in > >

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Tue, Aug 16, 2016 at 6:40 AM, Stack wrote: > On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang 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 > >

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Aug 16, 2016 00:24, "张铎" wrote: > > Yes, with jdk8 we could add new methods in interface without breaking the > sub classes. > > So let's revert HBASE-15645 from branch-1 and branch-1,x and add default > implementations in master? Is yetus OK to run pre-commit with jdk8

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang 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 >

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

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 ) and waiting for the result of pre-commit build. The patch

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Sorry for breaking the compatibility of Table interface. As the author of HBASE-15645, I can help making a new patch that only fixes the bug and not adding any new methods to Table.

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Yes, with jdk8 we could add new methods in interface without breaking the sub classes. So let's revert HBASE-15645 from branch-1 and branch-1,x and add default implementations in master? Is yetus OK to run pre-commit with jdk8 only on master now? Thanks. 2016-08-16 13:12 GMT+08:00 Sean Busbey

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Mon, Aug 15, 2016 at 10:09 PM, Sean Busbey wrote: > On Mon, Aug 15, 2016 at 10:55 PM, Andrew Purtell > > wrote: > > > > Are we extending this to all interfaces? Do we support folks > > implementing their own Connection? Admin? > > > > This will

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Tue, Aug 16, 2016 at 12:09 AM, Sean Busbey wrote: > > Moving from interfaces to abstract classes requires a deprecation cycle, > so to transition I think we'd need to introduce a new API. Anyone up for > this in 2.0? > I just remembered that HBase 2.0 is moving to jdk8+,

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Mon, Aug 15, 2016 at 10:55 PM, Andrew Purtell wrote: > > Are we extending this to all interfaces? Do we support folks > implementing their own Connection? Admin? > > This will bury us in weeds and bikeshedding. We can make a blanket rule > about source compatibility

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

I agree with Sean here. Interfaces with @Private annotations are going to be a problem. I think we should strongly discourage this. Either allow abstract classes are don't allow such things. We should have a note about this in the compatibility guide. Even regarding the Util classes and the

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

> Are we extending this to all interfaces? Do we support folks implementing > their own Connection? Admin? This will bury us in weeds and bikeshedding. We can make a blanket rule about source compatibility appropriately scoped to minors and/or patches without that drama. To wit: > So when I

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Sorry I missed this other thing I wanted to comment on: On Mon, Aug 15, 2016 at 2:07 PM, Josh Elser wrote: > > > > 3) What do people think about changing this in a 1.2.3 with a quick > turn-around? > > I'm actually behind cadence for 1.2.3 by about a week, so I'm fine

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Thanks for bringing this up Josh! On Mon, Aug 15, 2016 at 2:21 PM, Andrew Purtell wrote: > > > ​ > 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

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

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 wrote: > On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell 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

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Thanks for the great reply, Andrew! Andrew Purtell wrote: ​ 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.

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Also, the change to Table (HBASE-15645) went out in both 1.1.5 and 1.2.2. On Mon, Aug 15, 2016 at 12:21 PM, Andrew Purtell wrote: > > > ​ > I find the InterfaceAudience annotations on this really strange. How can > we have a Public audience Interface (o.a.h.h.c.Table) with

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

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

Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

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