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.
>

Reply via email to