> > Anyway let’s assume for now you want to unify all the branches for HBase > 1.x. Start with the lowest HBase version you want to support. Then iterate > up to the highest HBase version you want to support. Whenever you run into > compile problems, make a new version specific maven module, add logic to > the parent POM that chooses the right one. Then for each implicated file, > move it into the version specific maven modules, duplicating as needed, and > finally fixing up where needed. > +1. So we want to use one branch to handle all hbase branches? But we still need to release multi src/bin tar for multi hbase versions?
Andrew Purtell <andrew.purt...@gmail.com> 于2020年1月15日周三 上午10:55写道： > Take PhoenixAccessController as an example. Over time the HBase interfaces > change in minor ways. You’ll need different compilation units for this > class to be able to compile it across a wide range of 1.x. However the > essential Phoenix functionality does not change. The logic that makes up > the method bodies can be factored into a class that groups together static > helper methods which come to contain this common logic. The common class > can remain in the core module. Then all you have in the version specific > modules is scaffolding. In that scaffolding, calls to the static methods in > core. It’s not a clever refactor but is DRY. Over time this can be made > cleaner case by case where the naive transformation has a distasteful > result. > > > > On Jan 14, 2020, at 6:40 PM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > >
