The idea of a separate repo with compatibility modules sounds appealing. This refinement has several advantages esp if we separate out the "compatibility API" from the actual compatibility module implementation:
1. We can choose certain major release lines of Hadoop and provide modules for those lines. 2. Customers wishing to support other Hadoop release lines can then create their own compatibility module. As long as the implement the API interfaces (or extend the API abstract classes), and get it to compile/work against their release of Hadoop, all is good. The API can be versioned along with hbase as a separate artifact. -----Original Message----- From: Sean Busbey <[email protected]> Sent: Thursday, May 30, 2019 9:06 AM To: [email protected] Cc: dev <[email protected]> Subject: Re: [DISCUSS] Publishing hbase binaries with different hadoop release lines What about moving back to having a per-major-version-of-hadoop compatibility module again that builds against one needed major version all the time? (Presumably with some shell script magic to pick the right one?) that would be preferable imho to e.g. producing main project binary tarballs per Hadoop version. Or! We could move stuff that relies on brittle Hadoop internals into its own repo (or one of our existing repos) and build _that_ with binaries for our supported Hadoop versions. Then in the main project we can include the appropriate artifact for the version of Hadoop we happen to build with (essentially leaving the main repo how it is) and update our "replace the version of Hadoop!" note to including replacing this "HBase stuff that's closely tied to Hadoop internals" jar as well. On Wed, May 29, 2019, 08:41 张铎(Duo Zhang) <[email protected]> wrote:
