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:
>>> 
>> 

Reply via email to