Good points. I'd say we branch as soon as we identify a large feature that should not be in 0.94or by the end of February, whatever comes first. That way we keep the committers work to a minimum as long as possible. Just my $0.02.
-- Lars ----- Original Message ----- From: Jonathan Hsieh <j...@cloudera.com> To: dev@hbase.apache.org Cc: Sent: Thursday, January 26, 2012 6:42 AM Subject: Re: hbase 0.94.0 Can you help me understand the significance cutting the branch a month from now? As a strawman -- now that 0.92 is out (and ideally just getting fixes and supportability improvements instead of new features), why don't we cut a branch even earlier and then just bring in the features we decide get into 0.94 branch as they land? Here's a rough pro/con, interested in learning about more opinions: Pros: It would allow the release manager to better manage scope and be more selective on which features make it in sooner. It would allow other features large features like the beginnings of wire-compatiblity (maybe one of the major 0.96 goals) to start landing in trunk sooner as 0.94 branch gets filled. Cons: More work for committers when code wants to land in multiple branches. Possible divergence if the current wish list features take longer to land than the 0.96 wishlist. Jon On Wed, Jan 25, 2012 at 8:34 PM, Stack <st...@duboce.net> wrote: > Lets branch end of february? No new features thereafter. Is this too > close in? Would be grand if 0.94.0 shipped before hbasecon. What > should 0.94.0 have in it? I don't mind if the list is short. > > Unless someone else wants too, I don't mind being release manager > (will try to run a tighter ship this time around). > > St.Ack > -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // j...@cloudera.com
