phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: [IMPORTANT] Some changes to branches and releases for 4.4+
Date Wed, 25 Mar 2015 06:13:38 GMT
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 <jamestaylor@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 <enis@apache.org
> <javascript:_e(%7B%7D,'cvml','enis@apache.org');>> wrote:
>
>>
>> On Tue, Mar 24, 2015 at 11:02 PM, James Taylor <jamestaylor@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 <enis@apache.org> wrote:
>>> > On Tue, Mar 24, 2015 at 5:09 PM, James Taylor <jamestaylor@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 <enis@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.soz@gmail.com
>>> >> >> >> > <javascript:_e(%7B%7D,'cvml','enis.soz@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
>>> >> >> >> >> <jamestaylor@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
>>> >> >> >> >>> <jamestaylor@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 <
>>> >> enis@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 <
>>> >> enis@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
>>> >> >> >> >>> >>>
>>> >> >> >> >>> >>>
>>> >> >> >> >>>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >>
>>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message