hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: HBASE 2.0
Date Tue, 04 Oct 2016 17:00:39 GMT
Not sure about the alpha/beta designations. It would be new for us, and I
think unnecessary because the numbering of our prior "developer preview"
releases made that clear. We could do that again by calling test releases
1.99.x. Just a thought. Even if we do use tags like alpha, I don't see much
of a distinction between alpha and beta - neither should be deployed to
production - although I suppose beta sends a signal that we are getting
close. But why not just roll another 1.99.x saying the same in the
announcement.

> 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.

This is great. I'm also on board for weekly cluster integration testing,
diagnosis of issues, and, hopefully, bug fixing. My plan was to resign as
0.98 RM in January and take that spare time and put it into making 2.0
real. Although your proposed timeline starts sooner it's all good.

> 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.

In addition, while we will start branch-2 by cloning master, nothing says
we can't also kick something out of branch-2 via revert should it prove
just not ready.

> 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).

For what it is worth, depending on the state of them, I would really like
to see the new AM, incremental backup/restore (with changes as discussed by
the community), PB3, and HLC. Let's see if it is possible to get them all
in and produce a high quality stable release. Implicitly: A simple 1.x to
2.x upgrade path with bulletproof rollback.



On Mon, Oct 3, 2016 at 11:10 PM, Stack <stack@duboce.net> wrote:

> All sounds excellent to me. Thanks Stephen and Matteo.
>
> As per Enis, only odd part is this alpha/beta categorization. We've not
> done that before. See the refguide where we talk up 'Development Series'
> just under the 'Pre 1.0 versions' section here:
> http://hbase.apache.org/book.html#hbase.versioning.pre10
>
> Would be sweet if we could get the logical tier inserted too before the
> release of hbase-2.0.0 (I know Matteo probably ruled it out as too far out
> to land in time but I'm the eternal optimist...)
>
> Thanks,
> M
>
>
>
>
>
> On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang <syuanjiangdev@gmail.com>
> wrote:
>
> > 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
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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