Seems related to https://issues.apache.org/jira/browse/PHOENIX-1731. 1.0.1-SNAPSHOT did not contain https://issues.apache.org/jira/browse/HBASE-13109. The current one does, which requires another change since the method signature is different between 0.98 patch and 1.0 patch.
I have pushed an addendum patch. Let's see whether it helps. Enis On Wed, Mar 25, 2015 at 3:52 PM, James Taylor <jamestay...@apache.org> wrote: > 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 > >>>>> >> >> >> >>> >>> > >>>>> >> >> >> >>> >>> > >>>>> >> >> >> >>> > >>>>> >> >> >> >> > >>>>> >> >> >> >> > >>>>> >> >> > > >>>>> >> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > >>>>> > >>>> > >>>> >
