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