The master branch already includes PHOENIX-1642, so we just keep it there. No need to revert anything or cherry-pick anything. Every commit being done to 4.x-HBase-1.x is being done for master (that's why it's just wasted overhead until it's needed).
Your plan sounds fine, except this step isn't necessary (and no revert of anything currently in master is necessary): - After we fork 4.x-HBase-1.0, we cherry-pick PHOENIX-1642. Thanks, James On Tue, Mar 24, 2015 at 10:53 PM, Enis Söztutar <e...@apache.org> wrote: > On Tue, Mar 24, 2015 at 5:09 PM, James Taylor <jamestay...@apache.org> > wrote: > >> I'm fine with a 4.4 release for HBase 1.0, but it depends on demand - >> do our users need this? > > > I think so. HBase-1.0 usage is picking up, and we already saw users asking > for it. Though as usual, everything depends on whether there is enough > bandwidth to do the actual work (in terms of release, testing, porting, > etc). > > >> 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? >> > > Forking 4.4 release for HBase-1.0 from master seems strange. We have to > revert back the version, and make sure that it is really identical to the > 4.x-HBase-0.98 branch except for PHOENIX-1642. However, if you think that > an extra branch is really a lot overhead, maybe we can do this: > - Delete 4.x-HBase-1.x now. > - Keep 4.x-HBase-0.98 and master branches. > - Fork 4.x-HBase-1.0 branch when whichever of these happens earlier: > -- 4.4 is about to be released > -- PHOENIX-1501, or PHOENIX-1681 or PHOENIX-1763 needs to be committed. > - After we fork 4.x-HBase-1.0, we cherry-pick PHOENIX-1642. > - When PHOENIX-1501/PHOENIX-1681 and PHOENIX-1763 is ready and HBase-1.1.0 > is released we can fork 1.1 branch. > > Will that work? I am up to doing the work as long as we have a plan. > > Enis > > >> >> 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 >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> > >> >> > >> > >> > >>
