hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: HBASE 2.0
Date Mon, 03 Oct 2016 23:42:53 GMT
Thanks Matteo and Stephen for stepping up. The plan makes sense to me.
Without saying "no" to incoming features and random improvements, it is
very hard to make a release happen. The way to say no, is to have an
explicit branch and start to selectively include patches.

Since we have done a couple of 0.95.x in preparation to 0.96, and 0.99.x in
preparation to 1.0, (and 0.89, etc) it is only natural to continue with
this approach for 2.0. We can use alpha or beta which are both fine.

We have done 3 of the 0.99 releases, and it has helped a lot. I, as a first
time RM at that time, was able to get the release machinery, scripts, jobs,
etc setup and ready in the couple of first releases so that each
incremental release was easier and easier. It also gives downstreamers and
others a compile/dependency target. Since we have semantic versioning now,
we should use the 2.0.0-alpha1 kind of naming, which also makes the
intention super clear to consumers.

For 0.95 / 0.99, we have carried out those releases as regular releases
with voting, etc. We also used jira to track the issues in the release the
same way a normal release would work. In that sense, we can create jira
versions for the upcoming releases and start to use those tags. Matteo or
Stephen can change the existing issues with tag 2.0.0 to be 2.0.0-alpha1


On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang <syuanjiangdev@gmail.com>

> Hello, All,
> It is time to discuss about the schedule of HBase 2.0 release.  HBase 2.0
> release is a big major release.  When we release 1.0, we had 0.99 as dev
> preview/beta release.  We should do something similar for the 2.0 release.

> Matteo and I talked about this.   We think about that we need some
> Alpha/Beta milestones before the RC and final Release-to-Web 2.0 release.
> I don't know whether there is any discussion on this community about the
> Alpha/Beta release criteria.  My proposal is that once we cut the branch-2,
> we should only have new features that are absolutely needed for major
> release (festures cannot be added in minor release) and those features
> should be "almost ready".  For Alpha releases, we can still accept these
> kind of features; for Beta release, only bug fixes and performance
> improvement on existing features (should we also accept existing feature
> improvement in Beta?  Maybe Beta 1, Not in Beta 2 - that is my take).
> This is a big release and requires a lot of work from Release Manager.  I
> asked Matteo whether I could help to be some kind of backup / hot-standby /
> assistant RM.  I think he is very happy to have someone to share some RM
> duties.  Thus, I will help make this 2.0 release as smooth as possible.
> Here is a tentative plan:
> - For now, we are thinking of creating branch-2 middle of this month and
> have 2.0-Alpha1 release at the end of this month or begin of Nov.  The
> definition of Alpha1 is that we could deploy to a cluster and it can do
> some simple CRUD and table DDLs; and not crash (of course, UT passing).
> - Then we will have 2.0-Alpha2 in 4-6 weeks after Apha1.  It would hold
> higher bar.  We will run some IT tests to make sure that it would
> functional.
> - At that time, we will lock down and not allow any new features, every 4-6
> weeks, we will have a Beta release (my realistic guess is that we would hit
> the US Christmas holiday at that time, so first Beta would take longer than
> 6 weeks).  For Beta release, we would fix bugs and do performance tuning.
> Planning to have 2 Betas.  (Question: in the past, do we need vote to have
> a Beta release?)
> - Once the code are in the stable stage, then we will have RCs and vote for
> the final release.
> Please let us know whether this is a reasonable approach that will make the
> release successful.
> Currently, we are aware of the following on-going new features for 2.0: new
> Assignment Manager, backup/restore, off-heap, protobuff 3, Hybrid Logical
> Clock, and maybe AsyncRegion / C++ client).  If you have a feature that
> wants to be part of 2.0 release, please send discussion to dev community
> and we can make a call on accepting/rejecting.
> Thanks
> Stephen

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