Is everyone happy with the regular rebase proposal for additional cdh branches? Some projects are not keen on rebasing.
On 12 Mar 2018 04:19, "James Taylor" <[email protected]> wrote: > This sounds great to me, Pedro. > Thanks! > James > > On Sun, Mar 11, 2018 at 3:30 PM Pedro Boado <[email protected]> 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 <[email protected]> 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" <[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! > > >> > > > >> > > > > > > > > > -- > > Un saludo. > > Pedro Boado. > > >
