For Spark, backporting to branch-1 makes sense since it is in hbase-spark module - only adds one line to root pom.xml. there has been frequent user query for when hbase-spark would be in an hbase release
On Thu, Mar 17, 2016 at 8:26 AM, Matteo Bertozzi <[email protected]> wrote: > If we cut master now we have > - no rolling upgrade (am switched to zkless only and the other code was > removed) > - no api compatibility (we removed the deprecated) > - Offheaping on the read path > - Spark > - MOB > - RS Groups > - some other stuff... > > is that worth a major? > The offheaping work is probably the one that cannot be backported and it > may be nice to have. > but stuff like spark, mob and RS Groups can be in a 1.x and avoid migration > pain, and those are probably the ones that some people wants to try now. > > If we have a 2.0 for features like Spark, Mob and RS Groups I'd like to > have it based on branch-1. At least users can move there without having to > worry about compatibility, even if the version number itself will probably > force the users to stick with the 1.x because the assumption is that > something will break or there is a migration required. > > On Thu, Mar 17, 2016 at 8:05 AM, Andrew Purtell <[email protected]> > wrote: > > > I don't think we need to do a major for RS groups. > > > > I do think Elliott's points can be addressed by getting a 2.0 out the > door > > soon containing whatever we have on deck now to go in. > > > > Probably not going to satisfy everyone here - but maybe? > > > > > > > On Mar 17, 2016, at 7:48 AM, Matteo Bertozzi <[email protected]> > > wrote: > > > > > > Why MOB and RegionServer Groups should be in a new major version and > > stuff > > > like the new RPC queue (HBASE-15136), date based tiered compactions > > > (HBASE-15181), special handling for system tables WALs (HBASE-13557), > > keep > > > table state in meta (HBASE-13017) or the Region Normalizer > (HBASE-13103) > > > are considered for or already in 1.x? > > > > > > to me, and probably most of the users, a new Major version means that > > APIs > > > will break, wire may break, there may be an upgrade of some sort and so > > on. > > > which is not true for MOB and RS groups. > > > > > > In case we do a major for RS groups and Mob will that still based on > the > > > 1.x branch? > > > > > > On Wed, Mar 16, 2016 at 11:23 PM, Andrew Purtell < > > [email protected]> > > > wrote: > > > > > >> I remember explicitly saying I was not against a backport of the MOB > > >> feature. You are misrepresenting my position a bit. Sure, I'm a > skeptic. > > >> Not a big deal because I don't think we can or should seek a blanket > > rule. > > >> Sometimes a feature will have sufficient interest and applicability > > that a > > >> backport is worth considering, and then there's a question of what > kind > > of > > >> risk the changes envisioned carry. RS groups as implemented are low > > risk. > > >> Meanwhile MOB is highly invasive. I think RS groups would have two > large > > >> production users soon after introduction into branch-1. I'm not sure > > about > > >> MOB. They are worth consideration on their own merits and on user > demand > > >> for them. > > >> > > >> Another thing we could do is get 2.0 started right now. Whatever major > > >> that doesn't make the cut could go into 3.0. I think the requests for > > these > > >> backports are coming because there is no near time horizon for a 2.0 > > >> release. So set it soon? > > >> > > >> > > >>> On Mar 16, 2016, at 9:27 PM, Elliott Clark <[email protected]> > wrote: > > >>> > > >>> On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell < > > >> [email protected]> > > >>> wrote: > > >>> > > >>>> Because I for one might well want to run RS groups in production > with > > >>>> branch-1 code without waiting for or dealing with the other stuff > > >> coming in > > >>>> any 2.0. > > >>> > > >>> > > >>> This is the same email that I sent for MOB. Which you agreed with > then. > > >> But > > >>> not now. There's nothing substantively different about this feature > > that > > >>> makes it different from any other feature. It's a large change that > > >> wasn't > > >>> there in 1.X line. > > >>> > > >>> I would like backups, and procedure v2 in 1.x. However even if it > > landed > > >>> tomorrow they shouldn't be back ported as it's a large feature that's > > not > > >>> ready. If we want anyone to ever upgrade major versions, then the new > > >>> features have to come along with the new apis. Other wise we will end > > up > > >> in > > >>> the same state that Hadoop has. > > >> > > >
