As much as possible, I'd like to avoid us getting into another situation
with 5.x where we have multiple branches. My hope was/is that we can
keep one Phoenix5 branch that works against an acceptable set of HBase
branches.
To me, that acceptable set of HBase branches is _a_ 2.1 and 2.2 release.
I don't think we need to support all 2.1.x or 2.2.x, nor do I think we
need to keep trying to maintain 2.0.x as it's already end of support by
the HBase community.
Thanks for updating your PR. I'll add this to my review queue.
On 12/12/19 1:52 AM, Istvan Toth wrote:
Hi!
I'd like to start a conversation about supporting HBase 2.2. in the
master branch.
https://issues.apache.org/jira/browse/PHOENIX-5268 has a slightly out of
date, but functional PR for HBase 2.2 support on master. (Please review
and comment if you have the time, I'll try to update the PR in the next
few days)
The reason that it is not a straightforward decision to merge it is that
applying that patch breaks compatibility with HBase 2.0.1, the current
base.
I can see the following outcomes:
- Do nothing
- Move master to HBase 2.2.2
- Fork master to Hbase-2.0 and Hbase-2.2 branches
- Build time compatibility modules
- Run time compatibility modules
- Something that I haven't thought of
Doing nothing is obviously not a long term solution, as the current
master doesn't work with any of the currently supported HBase branches,
but we may postpone the inevitable.
Simply moving master to HBase 2.2 is the most attractive solution from a
pure developer POV, but there may be other considerations.
Having multiple masters for 2.0 and 2.2 is simple from a code
perspective, but maintaining two branches is a non-trivial amount of
additional work. (See the 4.x situation)
Moving the HBase version dependent stuff into a separate module, and
choosing at build time is not pretty from a code POV, but saves us the
hassle of maintaining multiple branches, while maintaining compatibility
with multiple HBase versions, and can handle future API changes as well
from a single branch. Doing something like this could have saved us the
effort of maintaining three separate 4.x branches.
I feel that since Phoenix is closely timed to HBase, and requires
cluster-wide HBase configuration to work anyway, handling the different
HBase versions from the same binary/JAR is not worth the effort.
Please share your thoughts!
regards
Istvan
