I suppose so, but release building is scripted. The build script can iterate over a set of desired HBase version targets and drive the build by setting parameters on the maven command line.
> On Jan 15, 2020, at 2:01 AM, Guanghao Zhang <zghao...@gmail.com> wrote: > > >> >> >> 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: >>> >>
