I've just confirmed that changes required for cdh5.12,5.13 and 5.14 are minimal ( just changes in pom.xml and PhoenixRpcScheduler needing a few more methods to be implemented for cdh > 5.12 ) . All IT running in all versions. We could keep one branch for each minor version ( and keep rebasing them to keep only one in sync ) , build, test and name after the latest patch version available.
My suggestion: - Create branch 4.x-cdh5.11.x on branch 4.x-cdh5.11.2 - and remove this branch - ( and keep compiling against cdh 5.11.2 until a new patch version 5.11.3 is made available) - Change parcels to be less restrictive, allowing to be installed regardless of the patch version ( for instance parcel 4.x-cdh5.11.x could be installed in >= 5.11.0 and < 5.12..0 ) . Parcel version will make clear what is the specific cdh version used to build that parcel ( same as now ) . - Create branch 4.x-cdh5.12.x ( compiling against cdh 5.12.2 until a new patch version is made available) . Keep rebasing onto cdh 4.x-cdh5.11.x - Create branch 4.x-cdh5.13.x ( compiling against cdh 5.13.2 until a new patch version is made available) . Keep rebasing onto cdh 4.x-cdh5.11.x - Create branch 4.x-cdh5.14.x ( compiling against cdh 5.14.2 until a new patch version is made available) . Keep rebasing onto cdh 4.x-cdh5.11.x I will take care of all cdh branches if everyone is happy with it. Cheers. On 10 March 2018 at 09:46, Pedro Boado <pedro.bo...@gmail.com> wrote: > 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" <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 >> 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! >> > >> > -- Un saludo. Pedro Boado.