I'm fine with a 4.4 release for HBase 1.0, but it depends on demand - do our users need this? I think doing that out of master will work and we can create a branch for the release like we do with our other releases.
When sub tasks of PHOENIX-1501 are ready, I think we'd want to put those in master and prior to that we'll need to create a 4.x-HBase-1.0. So we'll save the overhead of maintaining duplicate branches until that point. Make sense? On Tue, Mar 24, 2015 at 4:50 PM, Enis Söztutar <e...@apache.org> wrote: >> >> We've been putting stuff on feature branches that need more time. When >> PHOENIX-1681 or other sub tasks of PHOENIX-1501 are ready (after >> HBASE-12972 is in), we'll need a branch specific to HBase 1.1. Until >> then, I think it's just unneeded overhead. > > > That is why the branch for 1.1 is not created yet. The current branch > 4.x-HBase-1.x supports ONLY HBase-1.0 release, not 1.1 release. I had named > the branch 1.x hoping that it will support both, but it seem that we cannot > do this. Should we rename the branch to 4.x-HBase-1.0 so that it is > explicit? I am assuming that we are still interested in making a Phoenix > release (4.4) which will support HBase-1.0.x series. If that is not the case > and we only want to support 1.1, we can make the decision at the expense of > users who want to run Phoenix with HBase 1.0 releases. > > HBASE-12972 will not be committed to HBase-1.0.x releases, only to 1.1.x > releases, which (with the other changes like HBASE-11544) requires yet > another branch or release vehicle for HBase-1.1 support, different than 1.0 > support. > >> >> >> >> >> >> > >> >> > On Tuesday, March 24, 2015, Enis Söztutar <enis....@gmail.com >> >> > <javascript:_e(%7B%7D,'cvml','enis....@gmail.com');>> wrote: >> >> > >> >> >> You mean get rid of 4.x-HBase-1.x branch? It is already created and >> >> >> has >> >> >> PHOENIX-1642. It builds with HBase-1.0, but not 1.1. >> >> >> >> >> >> Enis >> >> >> >> >> >> On Sun, Mar 22, 2015 at 12:33 PM, James Taylor >> >> >> <jamestay...@apache.org> >> >> >> wrote: >> >> >> >> >> >>> I think we can stick with just 4.x-HBase-0.98 and master branch for >> >> >>> now until we need to work simultaneously on a Phoenix release that >> >> >>> supports both HBase 1.0 and HBase 1.1. Seems like the earliest >> >> >>> would >> >> >>> be closer to an HBase 1.1 release. Any idea when that might be? >> >> >>> Otherwise, the overhead of keeping master in sync with >> >> >>> 4.x-HBase-1.x >> >> >>> is wasted effort (as they'll be exactly the same until then). >> >> >>> >> >> >>> Thoughts? >> >> >>> >> >> >>> On Fri, Mar 20, 2015 at 4:53 PM, James Taylor >> >> >>> <jamestay...@apache.org> >> >> >>> wrote: >> >> >>> > Is this fixed yet? If not, would it be possible for you to set >> >> >>> > the >> >> >>> > pom >> >> >>> > to HBase-1.0.1 instead so that master will build? Just don't want >> >> >>> > to >> >> >>> > leave it in a broken state. >> >> >>> > Thanks, >> >> >>> > James >> >> >>> > >> >> >>> > On Thu, Mar 19, 2015 at 7:31 PM, Enis Söztutar <e...@apache.org> >> >> >>> wrote: >> >> >>> >> About the 4.x-HBase-1.x branch, it seems that I have spoken too >> >> >>> >> soon. >> >> >>> >> Current branch head does not compile with latest >> >> >>> >> HBase-1.1.0-SNAPSHOT: >> >> >>> >> >> >> >>> >> It seems the RegionScanner changes are the problem. Let me look >> >> >>> >> into >> >> >>> how we >> >> >>> >> can resolve those for future compatibility. >> >> >>> >> >> >> >>> >> Enis >> >> >>> >> >> >> >>> >> On Thu, Mar 19, 2015 at 2:15 PM, Enis Söztutar <e...@apache.org> >> >> >>> wrote: >> >> >>> >> >> >> >>> >>> Hi, >> >> >>> >>> >> >> >>> >>> As per private PMC threads and the dev discussions [1], I have >> >> >>> created two >> >> >>> >>> new branches for 4.x development for supporting both HBase-0.98 >> >> >>> >>> and >> >> >>> >>> HBase-1.0 versions. The goal is to have 4.4.0 and 4.5.0, etc >> >> >>> releases which >> >> >>> >>> support both of the HBase versions and possibly HBase-1.1.0+ as >> >> >>> >>> well. >> >> >>> >>> >> >> >>> >>> See [1] for why the branches are needed (this seems like the >> >> >>> >>> least >> >> >>> bad >> >> >>> >>> approach). Here are the changes I did for this: >> >> >>> >>> >> >> >>> >>> BRANCH CHANGES: >> >> >>> >>> - Committed PHOENIX-1642 to master >> >> >>> >>> - Created branch-4.x-HBase-0.98. Pushed to git repo >> >> >>> >>> - Created branch-4.x-HBase-1.x. Pushed to git repo >> >> >>> >>> - Changed versions to be 4.4.0-HBase-0.98-SNAPSHOT and >> >> >>> >>> 4.4.0-HBase-1.x-SNAPSHOT respectively in above branches >> >> >>> >>> - Cherry-picked PHOENIX-1642 to branch-4.x-HBase-1.x >> >> >>> >>> - Deleted branch named "4.0". (there is no rename of branches >> >> >>> >>> in >> >> >>> >>> git) >> >> >>> >>> >> >> >>> >>> I have named the branch 4.x-HBase-1.x instead of suffix >> >> >>> >>> HBase-1.0 >> >> >>> >>> in >> >> >>> hopes >> >> >>> >>> that further HBase-1.1, 1.2 can be supported in this branch and >> >> >>> >>> we >> >> >>> can get >> >> >>> >>> away without branching again for 1.1. See especially >> >> >>> >>> HBASE-12972. >> >> >>> >>> We >> >> >>> can >> >> >>> >>> change this later on if it is not the case. >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> JENKINS CHANGES: >> >> >>> >>> - Disabled Phoenix-4.0 job (Lets keep it around for a couple of >> >> >>> >>> days >> >> >>> just >> >> >>> >>> in case) >> >> >>> >>> - Created new jobs for these two branches: >> >> >>> >>> >> >> >>> >>> https://builds.apache.org/view/All/job/Phoenix-4.x-HBase-0.98/ >> >> >>> >>> https://builds.apache.org/job/Phoenix-4.x-HBase-1.x/ >> >> >>> >>> >> >> >>> >>> The build should be similar to the previous 4.0 branch builds. >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> JIRA CHANGES: >> >> >>> >>> - Renamed release version 4.4 in jira to 4.4.0 >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> Further changes coming shortly unless objection: >> >> >>> >>> - Delete jenkins job >> >> >>> >>> https://builds.apache.org/view/All/job/Phoenix%202.0/ (does >> >> >>> >>> not >> >> >>> seem to >> >> >>> >>> be used for more than 1 year) >> >> >>> >>> - Delete jenkins job >> >> >>> https://builds.apache.org/view/All/job/Phoenix-2.0/ >> >> >>> >>> - Delete jenkins job >> >> >>> https://builds.apache.org/view/All/job/Phoenix-4.0/ >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> How does this affect development and releases? >> >> >>> >>> - Current master is version 5.0.0-SNAPSHOT. It builds with >> >> >>> >>> HBase-1.0.1-SNAPSHOT (from apache snapshots repo). >> >> >>> >>> - branch-4.x-HBase-0.98 is very similar to old 4.0 branch. It >> >> >>> builds with >> >> >>> >>> HBase-0.98.9-hadoop2 >> >> >>> >>> - branch-4.x-HBase-1.x is forked from branch-4.x-HBase-0.98 >> >> >>> >>> and >> >> >>> builds >> >> >>> >>> with HBase-1.0.1-SNAPSHOT. >> >> >>> >>> - There should be two release artifacts (or releases >> >> >>> simultaneously) for >> >> >>> >>> 4.4 release. One will have version 4.4.0-HBase-0.98 and the >> >> >>> >>> other >> >> >>> >>> 4.4.0-HBase-1.x. We can make it so that the RM creates both >> >> >>> >>> releases >> >> >>> at the >> >> >>> >>> same time, and the VOTE applies to both releases. >> >> >>> >>> - All changes MUST be committed to both branches for future >> >> >>> >>> 4.x >> >> >>> releases >> >> >>> >>> unless it is HBase version specific. There is no way to >> >> >>> >>> auto-enforce >> >> >>> it, so >> >> >>> >>> all committers should take this into account. The patches might >> >> >>> differ >> >> >>> >>> sligtly. Before the release RM may do some manual checks to >> >> >>> >>> ensure >> >> >>> that >> >> >>> >>> every patch is commmitted to both branches. >> >> >>> >>> - Old 4.0 is deleted from git repository. Please re-check or >> >> >>> >>> rename >> >> >>> your >> >> >>> >>> local branches. Please do not push anything there (as it will >> >> >>> re-create the >> >> >>> >>> branch). >> >> >>> >>> - There is only one jira version 4.4.0, which should apply >> >> >>> >>> equally >> >> >>> to >> >> >>> >>> both release versions. If needed we can differentiate these in >> >> >>> >>> jira >> >> >>> as >> >> >>> >>> well. Let me know. >> >> >>> >>> - Before the 4.4.0 release, RM should fork both 4.x branches >> >> >>> >>> and >> >> >>> name >> >> >>> >>> them 4.4-HBase-XXX. At that time, we will have 1 master branch, >> >> >>> >>> 2 >> >> >>> >>> of >> >> >>> 4.x >> >> >>> >>> branches and 2 of 4.4 branches. >> >> >>> >>> >> >> >>> >>> Let me know if you have further concerns. Let's see how well >> >> >>> >>> this >> >> >>> process >> >> >>> >>> works. >> >> >>> >>> >> >> >>> >>> Thanks, >> >> >>> >>> Enis >> >> >>> >>> >> >> >>> >>> Ref: >> >> >>> >>> [1] http://search-hadoop.com/m/lz2la1GgkPx >> >> >>> >>> >> >> >>> >>> >> >> >>> >> >> >> >> >> >> >> > >> > > >
