It does seem better to put it back in tree with core because core will be branched, and would allow for the usual way we vary features and compatibility by code line.
> On Aug 29, 2019, at 11:14 AM, Stack <[email protected]> wrote: > >> On Thu, Aug 29, 2019 at 5:12 AM Peter Somogyi <[email protected]> wrote: >> >> Hi everyone, >> >> This topic came up a couple of times already but now we reached a point >> when the recent HBCK2 is incompatible with older HBase releases, >> specifically 2.0.x, 2.1.0 and 2.1.1. When you build HBCK2 against one of >> the previously mentioned releases you will get compilation errors. (mvn >> clean install -DskipTests -Dhbase.version=2.0.6) >> >> Our previous goal was to maintain compatibility with HBCK2 and all HBase 2 >> releases. Now we missed this target. >> >> > Was being able to build against all hbase2s a target? Didn't know. > > > >> One option that we could do is to have different branches/releases of HBCK2 >> targeted for specific HBase releases (e.g. branch-2.0 version of HBCK2). >> This probably makes the development on HBCK2 a bit harder since we'll have >> to take care of multiple branches. >> >> > This would defeat the whole reason for moving hbck2 out of core. Better to > just have hbck2 in hbase rather than do this. > > >> Another option I could think of is to always build HBCK2 with the latest >> HBase release but have version checks on individual commands where we could >> decide if it is supported on that release line. >> >> > This is what we have now [1]. > > S > > 1. > https://github.com/apache/hbase-operator-tools/blob/master/hbase-hbck2/src/main/java/org/apache/hbase/HBCK2.java#L105 > > >> What are your opinions on this? >> >> Thanks, >> Peter >>
