Is JanusGraph 1.0.z is compatible with HBase 2.2.z

[narenderrana]

From JanusGraph portal i am seeing JanusGraph 1.0.z is compatible with 2.5.z.

We are in scenario to use it with HBase 2.2.z

• What all possible issues we can face .
• How compatibility are tested with different versions of storage, I mean if I need to perform a compatibility check on HBase 2.2.z what will be the right approach.?

[FlorianHockmann]

I think it should be compatible with that version in general, but we only test against 2.5.
The testing documentation contains a section on how to run HBase tests which also mentions the property hbase.docker.version.
The section itself is relatively short, but it should be similar to the section above that. I guess it should work like this:

mvn clean install -pl janusgraph-hbase -Dhbase.docker.version=2.2.0

[narenderrana]

FlorianHockmann

After running above mvn command , total 336 test cases are passed and 6 test cases got skipped but no failure so all should be ok correct ?

Attaching the file .
JG1.0.0-HBase-2.2.3-test-cases-result.txt

Is there any way i can contribute to update the 1.0.z compatibility matrix with Hbase 2.2.z in portal as it leave impression that only 2.5.z is supported.

[FlorianHockmann]

After running above mvn command , total 336 test cases are passed and 6 test cases got skipped but no failure so all should be ok correct ?

Yes, that's looking good. Great to hear that you got it working locally and that 1.0.0 is still compatible with that HBase version.

Is there any way i can contribute to update the 1.0.z compatibility matrix with Hbase 2.2.z in portal as it leave impression that only 2.5.z is supported.

It's easy to change the compatibility matrix, but I'm not sure whether we want to do that. The matrix should only claim compatibility if we have automated tests in place to verify the compatibility. Otherwise, we may accidentally break compatibility in the next release (like 1.0.1), for example simply by merging some dependency update, without us noticing it.
So we would need to run additional test workflows for this HBase version. However, we also already execute all HBase tests at least twice: once for Java 8 and then again for Java 11. Adding another HBase version would mean that we have to execute them 4 times.
Our workflows already take a long time on GitHub which makes me hesitant to just execute all HBase tests twice as often. We do execute tests for different versions for other backends, but then it's usually because of different major versions that we support, like Elasticsearch 6, 7, and 8, or Cassandra 3 and 4.

However, I have to say that HBase is not really my area of expertise. Is there a good reason to specifically test this specific version in addition to HBase 2.5?

[narenderrana]

I understand your point it will increase build automation time.

Reason to include this i would say it will increase more trust on HBase backward compatibility as seeing only 2.5 in the list gave impression that it support only 2.5 . Would be great if can include few more HBase major versions, just a suggestion.