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 >
