PHOENIX-7027 Add compatibility module for Hbase 2.5.4 and upgrade Hba… #1679
Conversation
stoty
requested review from
virajjasani,
gjacoby126 and
richardantal
and removed request for
virajjasani and
gjacoby126
| </activation> | ||
| <properties> | ||
| <hbase.profile>2.5.0</hbase.profile> | ||
| <hbase.compat.version>2.5.0</hbase.compat.version> |
There was a problem hiding this comment.
shall we keep this also 2.5.4 just to maintain same compat version as before?
There was a problem hiding this comment.
The convention we have used so far is that the profile activated by the property without patch level, i.e. 2.5 always points to the latest supported HBase patch level (and corresponding compatibility module) within that minor version.
When we need to add a new profile, we move the patch level-less profile property value to point to the latest one, and create a new profile which is named after the first patch level it supports.
Before this patch the -Dhbase.profile=2.5 activated 2.5.0 profile id which used the existing 2.5.0 compatibility moudule.
Now the -Dhbase.profile=2.5 value activates 2.5.4 profile and module instead, and we've added the new 2.5.0 property value match to the old 2.5.0 compatibility module.
Yes, this means that you have to change the profile if you keep using an older HBase version, but 2.5 profile always works with the latest 2.5 release. We can't have it both ways unfortunately.
We could add an explicit 2.5.4 profile as an alias to 2.5, but I don't think that would improve things.
There was a problem hiding this comment.
However, the profile id is indeed inconsistent.
We should call it phoenix-hbase-compat-2.5.4 instead.
|
build#1 timed out after 9+ hr, triggered new build: https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1679/2/ |
…se version to 2.5.5
…se version to 2.5.5