Re: Handling of HBase version specifics.
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 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 > 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 la...@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 > > > > > >
Re: [VOTE] Release of Apache Phoenix 4.14.2 RC1
+1 Jaanai Zhang Best regards! Thomas D'Silva 于2019年5月18日周六 下午3:38写道： > Hello Everyone, > > This is a call for a vote on Apache Phoenix 4.14.2 RC1. This is a patch > release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and 1.4. > The release includes both a source-only release and a convenience binary > release for each supported HBase version. > > This release has feature parity with supported HBase versions and includes > several critical bug fixes. > > The source tarball, including signatures, digests, etc can be found at: > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc1/src/ > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc1/src/ > > The binary artifacts can be found at: > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc1/bin/ > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc1/bin/ > > For a complete list of changes, see: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12344379 > > Artifacts are signed with my "CODE SIGNING KEY": DFD86C02 > > KEYS file available here: > https://dist.apache.org/repos/dist/dev/phoenix/KEYS > > The hash and tag to be voted upon: > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=e3505d91e46de1a1756a145d396f27a3c70e927f > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=4b717825fb284c1f9fbdeee3d0e5391f5baf13bb > > > Vote will be open for at least 72 hours. Please vote: > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Thanks, > The Apache Phoenix Team >
Re: Handling of HBase version specifics.
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 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 la...@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 > > >
