You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stephen Jiang <sy...@gmail.com> on 2016/10/03 22:27:34 UTC
HBASE 2.0
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
Re: HBASE 2.0
Posted by Ted Yu <yu...@gmail.com>.
w.r.t. feature, there is also:
HBASE-15968 MVCC-sensitive semantics of versions
On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang <sy...@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
>
Re: HBASE 2.0
Posted by Yu Li <ca...@gmail.com>.
Thanks for bring this up Stephen, great to know a detailed plan for 2.0,
have been expecting that for some time. :-)
w.r.t new features, I hope we could also include the below two:
1. AsyncTable (HBASE-15921)
2. Netty-based RpcServer (HBASE-15756 bring up the idea and we'll open new
JIRA to make it more specific, which shows great performance gain in our
use case here in Alibaba search)
Thanks.
Best Regards,
Yu
On 6 October 2016 at 22:01, Sean Busbey <bu...@cloudera.com> wrote:
> On Tue, Oct 4, 2016 at 12:00 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> >> 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.
>
>
> I'd like to get our use of HDFS cleaned up in time for 2.0; so far it
> looks like it'll probably impact some of our operational tooling.
>
> I don't think it ought to be a blocker, so I'm aiming for the
> something later than the first round of early-releases
> (alpha/beta/whatever we're calling it).
>
> --
> busbey
>
Re: HBASE 2.0
Posted by Sean Busbey <bu...@cloudera.com>.
On Tue, Oct 4, 2016 at 12:00 PM, Andrew Purtell <ap...@apache.org> wrote:
>> 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.
I'd like to get our use of HDFS cleaned up in time for 2.0; so far it
looks like it'll probably impact some of our operational tooling.
I don't think it ought to be a blocker, so I'm aiming for the
something later than the first round of early-releases
(alpha/beta/whatever we're calling it).
--
busbey
Re: HBASE 2.0
Posted by Andrew Purtell <ap...@apache.org>.
> Do we have to do this? It will cost a load of dev time that I suggest
would be better spent on ensuring the forward migration just 'works'.
Maybe? I think it's fine to put it on the table as something we should do
as a stretch goal. It might not be possible given our constraints, but is a
good idea.
On Tue, Oct 4, 2016 at 10:10 AM, Stack <st...@duboce.net> wrote:
> On Tue, Oct 4, 2016 at 10:00 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > ...A simple 1.x to 2.x upgrade path
>
>
> +1
>
>
>
> > ....with bulletproof rollback.
> >
> >
> >
> Do we have to do this? It will cost a load of dev time that I suggest would
> be better spent on ensuring the forward migration just 'works'.
>
> S
>
>
>
>
> >
> > On Mon, Oct 3, 2016 at 11:10 PM, Stack <st...@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)
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: HBASE 2.0
Posted by Stack <st...@duboce.net>.
On Tue, Oct 4, 2016 at 10:00 AM, Andrew Purtell <ap...@apache.org> wrote:
> ...A simple 1.x to 2.x upgrade path
+1
> ....with bulletproof rollback.
>
>
>
Do we have to do this? It will cost a load of dev time that I suggest would
be better spent on ensuring the forward migration just 'works'.
S
>
> On Mon, Oct 3, 2016 at 11:10 PM, Stack <st...@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 <sy...@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)
>
Re: HBASE 2.0
Posted by Andrew Purtell <ap...@apache.org>.
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 <st...@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 <sy...@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)
Re: HBASE 2.0
Posted by Stack <st...@duboce.net>.
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 <sy...@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
>
Re: HBASE 2.0
Posted by Enis Söztutar <en...@apache.org>.
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
instead.
Enis
On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang <sy...@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
>
Re: HBASE 2.0
Posted by Dima Spivak <di...@apache.org>.
SGTM. I've already allocated some time for the next few months to improve
our upstream integration testing story, so it looks like that'll jibe well
with the 2.0 release cycle.
Yay, this looks fun.
-Dima
On Mon, Oct 3, 2016 at 3:27 PM, Stephen Jiang <sy...@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
>