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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','e...@apache.org');>> wrote:
>> > On Tue, Mar 24, 2015 at 5:09 PM, James Taylor <jamestay...@apache.org
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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');>
>> >> >> >> > <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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
>> >> >> >> >>> >>>
>> >> >> >> >>> >>>
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >>
>>
>
>

Reply via email to