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
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" <jamestay...@apache.org> 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 <pbo...@apache.org> wrote:
> > Hi all,
> > After our first release of Phoenix for CDH 5.11.2 it looks like a good
> > 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
> > (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
> > 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
> > 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
> > and more web server space needed for keeping several parcels ( I'm not
> > sure if that is an issue )
> > All ideas are welcome.
> > Thanks!