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.

Reply via email to