Sounds like a plan. I changed the pom and MetaDataProtocol version to 4.4.0 on master, so we're all set there.
If you could look at why our master build is failing, that'd be good. Looks like the 1.0.1-SNAPSHOT build is messed up. We're getting this exception for every unit test: Caused by: java.lang.NoSuchFieldError: NO_NEXT_INDEXED_KEY at org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.reseekTo(HFileReaderV2.java:590) at org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseekAtOrAfter(StoreFileScanner.java:267) at org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:181) at org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:55) at org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:312) On Wed, Mar 25, 2015 at 11:30 AM, Enis Söztutar <e...@apache.org> wrote: > Ok great. I'll continue with the plan then. I'll send an update again for > devs to notify about the end state as not every one might be following > closely. > > Enis > > On Tue, Mar 24, 2015 at 11:13 PM, James Taylor <jamestay...@apache.org> > wrote: > >> 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> 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 >>>>> >> >> >> >>> >>> >>>>> >> >> >> >>> >>> >>>>> >> >> >> >>> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> > >>>>> >> >> > >>>>> >> > >>>>> >> > >>>>> >> >>>>> >>>> >>>>
