> 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 <[email protected]> wrote: > On Tue, Oct 4, 2016 at 10:00 AM, Andrew Purtell <[email protected]> > 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 <[email protected]> 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 <[email protected] > > > > > 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)
