phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Handling of HBase version specifics.
Date Mon, 20 May 2019 04:18:05 GMT
I think it’s a good idea, but even before this you have to ask when a
Jenkins build actually succeeded. How about solving that first?

On Sun, May 19, 2019 at 1:34 PM Nick Dimiduk <ndimiduk@gmail.com> wrote:

> I think this is generally a good idea for managing multiple target
> runtimes.
>
> One question I have though: is it really necessary that we support so many
> release branches and so many compile targets? What about the versions of
> Hadoop underneath each of those versions of HBase? Are we committed to
> running against ever version of HDFS that each of those HBase releases
> support? The test load will be massive and the suite itself must be
> rock-solid in order to run across so many permutations. I fear that’s an
> unreasonable burden for an open source community.
>
> Thanks,
> Nick
>
> On Sat, May 18, 2019 at 11:36 AM Thomas D'Silva
> <tdsilva@salesforce.com.invalid> wrote:
>
> > +1, I think this is a good idea. This would make it easier to contribute
> > and commit since you would only have to create a single patch.
> > The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should
> make
> > sure our precommit build will run the tests for all the modules.
> >
> >
> >
> > On Fri, May 17, 2019 at 11:23 AM larsh@apache.org <larsh@apache.org>
> > wrote:
> >
> > > Hi all,
> > > historically we have a branch of each version of HBase we want to
> > > support.As a result we have many branches, committing is a hassle and
> it
> > is
> > > easy to miss a change across branches.
> > > Instead we could have a maven module per version of HBase we want to
> > > support and move the version dependent code there.Take a look at what
> > > Tephra is doing: https://github.com/apache/incubator-tephra
> > > They have a compat module for each supported version of HBase, and
> > version
> > > dependent code is "simply" copied into those modules.There's still
> > > duplicate code, but at least there's one branch to maintain.
> > > It's somewhat of a bigger project now.
> > > Thoughts?
> > > -- Lars
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message