Since HBase 2.0 is EOM'ed, I'm +1 for not worrying about 2.0.x compatibility with the 5.x branch going forward.
Given how coupled Phoenix is to the implementation details of HBase though, I'm not sure trying to abstract those away to keep one Phoenix branch per HBase major version is practical, however. At the least, it would be really complex. For example, in the new year I plan to return to working on the change data capture and Phoenix-level replication features, both of which depend on WALKey interface changes and a new RegionObserver coprocessor hook introduced in HBASE-22622 and HBASE-22623. This was released in HBase 1.5 and will be in the forthcoming HBase 2.3. While the HBase community is discussing EOMing 1.3 right now, and maybe 1.4 will go in the medium term, I don't see all pre-2.3 branch-2's getting deprecated anytime soon. So there will be at least two significant features that can only exist in some but not all of our 4.x and 5.x branches. Geoffrey On Thu, Dec 12, 2019 at 8:21 AM Josh Elser <els...@apache.org> wrote: > As much as possible, I'd like to avoid us getting into another situation > with 5.x where we have multiple branches. My hope was/is that we can > keep one Phoenix5 branch that works against an acceptable set of HBase > branches. > > To me, that acceptable set of HBase branches is _a_ 2.1 and 2.2 release. > I don't think we need to support all 2.1.x or 2.2.x, nor do I think we > need to keep trying to maintain 2.0.x as it's already end of support by > the HBase community. > > Thanks for updating your PR. I'll add this to my review queue. > > On 12/12/19 1:52 AM, Istvan Toth wrote: > > Hi! > > > > I'd like to start a conversation about supporting HBase 2.2. in the > > master branch. > > > > https://issues.apache.org/jira/browse/PHOENIX-5268 has a slightly out of > > date, but functional PR for HBase 2.2 support on master. (Please review > > and comment if you have the time, I'll try to update the PR in the next > > few days) > > > > The reason that it is not a straightforward decision to merge it is that > > applying that patch breaks compatibility with HBase 2.0.1, the current > > base. > > > > I can see the following outcomes: > > > > - Do nothing > > - Move master to HBase 2.2.2 > > - Fork master to Hbase-2.0 and Hbase-2.2 branches > > - Build time compatibility modules > > - Run time compatibility modules > > - Something that I haven't thought of > > > > > > Doing nothing is obviously not a long term solution, as the current > > master doesn't work with any of the currently supported HBase branches, > > but we may postpone the inevitable. > > > > Simply moving master to HBase 2.2 is the most attractive solution from a > > pure developer POV, but there may be other considerations. > > > > Having multiple masters for 2.0 and 2.2 is simple from a code > > perspective, but maintaining two branches is a non-trivial amount of > > additional work. (See the 4.x situation) > > > > Moving the HBase version dependent stuff into a separate module, and > > choosing at build time is not pretty from a code POV, but saves us the > > hassle of maintaining multiple branches, while maintaining compatibility > > with multiple HBase versions, and can handle future API changes as well > > from a single branch. Doing something like this could have saved us the > > effort of maintaining three separate 4.x branches. > > > > I feel that since Phoenix is closely timed to HBase, and requires > > cluster-wide HBase configuration to work anyway, handling the different > > HBase versions from the same binary/JAR is not worth the effort. > > > > Please share your thoughts! > > > > regards > > Istvan > > >
