I'd generally vote for a time-based release. The "big feature" releases while are good for attracting new users with new features, present a problem in that it can really delay releases for a long time. More releases are better! If a feature takes more than 3 months then it's too big to implement in one go.
On Mon, Feb 28, 2011 at 2:00 PM, Todd Lipcon <t...@cloudera.com> wrote: > On Sat, Feb 26, 2011 at 2:24 PM, Jean-Daniel Cryans <jdcry...@apache.org> > wrote: >> Woah those are huge tasks! >> >> Also to consider: >> >> - integration with hadoop 0.22, should we support it and should we >> also support 0.20 at the same time? 0.22 was branched but IIRC it >> still has quite a few blockers. >> - removing heartbeats, this is in the pipeline from Stack and IMO >> will have ripple effects on online schema editing. >> - HBASE-2856, pretty critical. >> - replication-related issues like multi-slave (which I'm working on), >> and ideally multi-master. I'd like to add better management tools too. >> >> And lastly we need to plan when we want to branch 0.92... should we >> target late May in order to be ready for the Hadoop Summit in June? >> For once it would be nice to offer more than an alpha release :) > > In my view, we can do one or the other: either it's a feature-based > release, in which case we "release it when it's done", or it's a > time-based release, in which case we release at some decided-upon time > with whatever's done. > > I personally prefer time-based releases, though we need to make sure > if we decide to do this that any large destabilizing (or half > complete) features are guarded either by config flags or are developed > in a branch. Thus trunk stays relatively releasable at all times and > we can be pretty confident we'll hit the decided-upon timeline. > > Looking back at the 0.90 release, we got caught in a bind because we > were trying to do both feature-based (new master) and time-based (end > of 2010). > > So, my vote is either: > plan a: hybrid model - 0.91.X becomes a time-based release series > where we drop trunk once every month or two, and 0.92.0 is gated on > features > or: > plan b: strict time-based: we release 0.92.0 around summit, and lock > down the branch at least a month or so ahead of time for bugfix only. > > Thoughts? > > -Todd > > >> >> On Sat, Feb 26, 2011 at 12:34 PM, Andrew Purtell <apurt...@apache.org> wrote: >>> Stack and I were chatting on IRC about settling with should get into 0.92 >>> before pulling the trigger on the release. >>> >>> Stack thinks we need online region schema editing. I agree because >>> per-table coprocessor loading is configured via table attributes. We'd also >>> need some kind of notification of schema update to trigger various actions >>> in the regionserver. (For CPs, (re)load.) >>> >>> I'd also really like to see some form of secondary indexing. This is an >>> important feature for HBase to have. All of our in house devs ask for this >>> sooner or later in one form or another. Other projects have options in this >>> arena, while HBase used to in core, but no longer. We have three people >>> starting on this ASAP. I'd like to at least do co-design with the >>> community. We should aim for 'simple and effective'. >>> >>> There are 14 blockers: >>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HBASE+AND+fixVersion+%3D+%220.92.0%22+AND+resolution+%3D+Unresolved+AND+priority+%3D+Blocker >>> >>> Additionally, 22 marked as critical: >>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HBASE+AND+fixVersion+%3D+%220.92.0%22+AND+resolution+%3D+Unresolved+AND+priority+%3D+Critical >>> >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. >>> - Piet Hein (via Tom White) >>> >>> >>> >>> >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
