Hi all, as discussed last week I've just pushed three more branches 4.x-cdh5.12 , 4.x-cdh5.13 and 4.x-cdh5.14. The three of them are fully functional and create parcels for each one of these versions. Parcels starting from today are now compatible across all minor versions.
I'll keep rebasing this three branches onto 4.x-cdh5.11 to keep changes to a minimum so please DO NOT PUSH Changes to any of these three branches. I've also renamed 4.x-cdh5.11.2 as 4.x-cdh5.11 . This will be (for now ) our base CDH branch so if you want to APPLY YOUR PATCHES please do it ON 4.x-cdh5.11 @JamesTaylor I've just noticed you've pushed 4.x-cdh5.11.2 again. I've reapplied all changes in 4.x-cdh5.11 and removed 4.x-cdh5.11.2 Is everyone happy with the approach? Cheers, Pedro. On 16 March 2018 at 22:13, Flavio Pompermaier <pomperma...@okkam.it> wrote: > Thnaks Pedro for the great effort! > > On Mon, 12 Mar 2018, 05:19 James Taylor, <jamestay...@apache.org> wrote: > > > This sounds great to me, Pedro. > > Thanks! > > James > > > > On Sun, Mar 11, 2018 at 3:30 PM Pedro Boado <pedro.bo...@gmail.com> > wrote: > > > > > 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. > > > > > > -- Un saludo. Pedro Boado.
