I can't comment whether we need every Hadoop release but at the minimum, 2.8.5 as we recently switched to it from 2.7.7. I ran into issues with 2.8.5 and 2.1.5rc0 and used workaround in https://issues.apache.org/jira/browse/HBASE-22052 to overcome it. I guess if 2.1 will not live past 2.1.6 then it's irrelevant. At the minimum we need to document steps to build an HBase binary with explicit Hadoop version. Yes, it's there but we need to do a better job bringing this information forward.
On a separate note, I ran into issues with 2.2rc4 and Hadoop 2.9.2 and plan to improve documentation for workarounds, initial thoughts are in https://issues.apache.org/jira/browse/HBASE-22465. I want to emphacose both sides of the coin, with strict durability and without. Thoughts welcome on the jira. On Wed, May 29, 2019, 9:41 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > See the comments here > > https://issues.apache.org/jira/browse/HBASE-22394 > > Although we claim that hbase 2.1.x can work together with hadoop 3.1.x, > actually we require users to build the hbase binary with hadoop 3.1.x by > their own if they really want to use hbase together with hadoop 3.1.x > clients. > > The problem for HBASE-22394 is that our asyncfswal references some > IA.Private classes and they have been changed between minor releases. It > can be solved by using reflection. But in general, since hadoop also > follows the semantic versioning, I do not think it is safe to do drop-in > replacement between minor releases. So maybe a better way is to publish a > hbase binary for each hadoop minor release line? > > Thanks. >
