We can actually just set the pom version and version in MetaDataProtocol to 4.4.0 now if we want.
On Tuesday, March 24, 2015, James Taylor <jamestay...@apache.org> wrote: > True, good point. We can revert those right after we branch in prep for a > 4.4 release on 1.0. > > On Tuesday, March 24, 2015, Enis Söztutar <e...@apache.org > <javascript:_e(%7B%7D,'cvml','e...@apache.org');>> wrote: > >> >> On Tue, Mar 24, 2015 at 11:02 PM, James Taylor <jamestay...@apache.org> >> wrote: >> >>> 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). >>> >> >> Like the pom.xml version, and >> https://issues.apache.org/jira/browse/PHOENIX-1766 have to be reverted >> if we fork the 4.x-HBase-1.0 branch from master, no? >> >> >>> >>> 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 >>> >> >> >> >>> >>> >>> >> >> >> >>> >>> >>> >> >> >> >>> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> > >>> >> >> > >>> >> > >>> >> > >>> >> >>> >> >>
