I rather prefer keeping several branches. Most of the changes in our cdh branch are related to a couple of interfaces in HBase 1.2-cdh that have included changes from Apache HBase 1.3 (as Apache HBase 1.2 is close to EOM, Cloudera keeps patching it's versions by applying some changes from HBase 1.3) and that Phoenix implements. Shim layer would make thing more complicated.
It's quite likely that the only change needed is at pom.xml level ( cdh version-specific grandparent pom and related properties in parent pom ) This could be solved by keeping our current 4.x-cdh-5.11.2 in sync ( renamed as 4.x-cdh5 ) with 4.x-HBase-1.2, and then keep rebasing supported version branches 4.x-cdh-5.11.2, 4.x-cdh-5.13.2, etc onto 4.x-cdh5 ~HEAD. On 10 Mar 2018 05:36, "James Taylor" <[email protected]> wrote: > If you're willing to sign up to keep the CDH branches in sync with the > 4.x-HBase-1.2 branches, then that seems fine. Should we look into some kind > of automation for syncing all the branches? > > Another approach is a shim layer, but we've been reluctant to set that up > as there's a fair amount of initial overhead to implement. > > On Thu, Mar 8, 2018 at 4:24 PM, Pedro Boado <[email protected]> wrote: > > > Hi all, > > > > After our first release of Phoenix for CDH 5.11.2 it looks like a good > idea > > expanding support to other newer versions. I'd like to discuss with you > > guys what would be the best approach as we have several options: > > > > - Releasing one single generated parcel with wider compatibility ( > > cloudera-labs phoenix style ) . The issue here is that all transitive > > dependencies packaged in phoenix fatjars would be specific to a cdh > version > > (let's say, cdh5.11.2) but would be running against different cdh version > > (maybe cdh5.14.0 ) . There is a small chance of incompatibility across > > versions ( even when all of them are HBase 1.2 based ) . Also we wouldn't > > be running our IT against all these cdh versions. > > > > - Maybe work further into packaging (and removing) any dependency that is > > already shipped in cdh. That would improve compatibility of this unique > > parcel version across cdh releases. But fat client fatjars would still > be a > > problem for use from out of hadoop cluster. > > > > - Release several parcels specific to different cdh versions ( my > favourite > > option ) . That is the safest option for better compatibility as we would > > be shipping the exact same libraries in the parcel as used in that > version > > of cdh. And we'd also be doing IT for several cdh versions. Downside is a > > little bit more of release effort ( not a big deal ) , more branches in > git > > and more web server space needed for keeping several parcels ( I'm not > > sure if that is an issue ) > > > > All ideas are welcome. > > > > Thanks! > > >
