Totally acknowledge and understand the scope of the problem, but I worry
about expanding our test-matrix more. I also worry that until we get
some LimitedPrivate/Public API for what asyncfswal needs out of Hadoop,
we'll be chasing our tail trying to maintain compatibility.
Is it possible for us to choose a Hadoop version (or two) that we
generally expect people to use and target that instead of going to minor
version?
For example, we could publish with Hadoop 2.8.latest and 3.1.latest. We
may work with versions beyond that, but we provide (as a service to our
users) some basic versions of Hadoop that they should be able to pull
off the shelf.
This isn't really different than what we do today, other than setting
different defaults for hadoop-two.version and hadoop-three.version. I
think it would be more in "communicating" to our downstream users that,
what we provide as a convenience, is expected to work against specific
Hadoop versions.
On 5/29/19 9:40 AM, 张铎(Duo Zhang) 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.
