> Hopefully, Phoenix will not find itself in a position where business-critical things it's doing are being removed from API (and Phoenix has no recourse to hack what it needs back in place).
I feel fairly confident this is going to happen given the radical excision of methods from the interfaces. What I hope is we can get a round of evaluation by the Phoenix folks of the fallout in between our introduction of these changes in an alpha before we cement the changes in a GA release. On Wed, Oct 18, 2017 at 11:50 AM, Josh Elser <els...@apache.org> wrote: > Yes, the earlier the better, but this is also a bit chicken-and-egg. It's > tough down in Phoenix to make sure it still works if the API we're trying > to write against is still changing. > > I know that Anoop from the HBase side has been peering into the Phoenix > side -- I've been operating under the assumption that things will be OK. > Hopefully, Phoenix will not find itself in a position where > business-critical things it's doing are being removed from API (and Phoenix > has no recourse to hack what it needs back in place). > > With an HBase hat on, I think Phoenix is a good candidate (among others > like YARN) for validating the alpha-4 release, signaling whether we're > actually ready to say HBase 2 is ready for a beta-1 (as opposed to an > alpha-5 to fix some more). > > Happy to entertain a broader discussion if you think there's merit on > dev@hbase too, S. > > > On 10/17/17 5:35 PM, Stack wrote: > >> Some notes on this effort: >> >> + Perhaps this discussion should be cc'd to dev@hbase? There is a good >> bit >> of overlap between dev-set here and dev-set on hbase and some >> interest/concern around Phoenix on HBase2. >> + Here are some notes I took after looking at Phoenix last week that I ran >> by James off-list (I filled in some of his feedback) [1]. The notes try to >> list what Phoenix uses from HBase core. I was looking to Coprocessor usage >> mostly. I noticed that CP-usage is mostly inside the bounds of appropriate >> use. It is elsewhere that P is in violation. >> + After my splunking and going by feedback from James, do we have to carry >> all of Phoenix over to hbase2? Can we drop some stuff that is not used >> anymore or can we work out an ordained API P could use instead of do its >> own workaround? >> >> It is late in the day to be having this conversation -- we are about to >> release alpha4 which is supposed to be locked-down internal and external >> API -- but better late than never. >> >> Thanks, >> St.Ack >> 1. https://docs.google.com/document/d/10cabwp_ >> aR3OmpHVoeh544YLC3KwqMD9KiTIrHZAmfec/edit#heading=h.7swwa1jl6wiw >> >> On Wed, Oct 11, 2017 at 3:00 PM, Josh Elser <els...@apache.org> wrote: >> >> Since 4.12.0 is out and we have the concurrent discussions about the 0.98, >>> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to >>> HBase >>> 2.0.0? >>> >>> The lack of chatter is pretty obvious that the Calcite work (the previous >>> impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4, >>> coprocessor API should stabilize and give us a point against which we can >>> start Phoenix work. >>> >>> Should a release of Phoenix that supports HBase 2.0 be worthy of the >>> Phoenix 5.0 label, or should we stick to the 4.x numbering? Given the >>> breaking changes going into HBase 2.0 and James' previous -1 to >>> shim-layers >>> for 0.98, do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x >>> a >>> different beast? I can see pros/cons for both sides. >>> >>> - Josh >>> >>> >> -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
