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:15:09 GMT
> 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 <stack@duboce.net> wrote:

> On Tue, Oct 4, 2016 at 10:00 AM, Andrew Purtell <apurtell@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 <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)
> >
>



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