hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: putting a border around 0.92 release
Date Tue, 01 Mar 2011 02:44:42 GMT
On Mon, Feb 28, 2011 at 2:18 PM, Jean-Daniel Cryans <jdcryans@apache.org> wrote:
> I think we tried a couple of times to release according to a schedule
> in the past but always failed, be it 0.2, 0.20 or 0.90, and always
> ended with something like an alpha or preview release at agreed-upon
> time.
> On on hand, releasing more often would give users access to features
> earlier (those already committed). On the other hand, when you are
> developing one feature and it takes a lot of time, you'd like to delay
> a release to have it included (kudos to the TM team who agreed on not
> putting CP in 0.90 when we thought it was only a few weeks from
> release and it ended up taking a few months to stabilize).

Yep, but I think this has been successful. The CP API as I understand
it has gone through a couple incompatible changes while living in
trunk as different people have started experimenting with it. Keeping
it away from the general userbase has allowed the API to coalesce into
something full-featured while not having to support a bunch of
backward-compatibility issues.

While we always have the temptation to throw out new features to
users, we have to keep in mind the support burden as well :)

> I'm +1 on time-based releases, but keeping huge patches in separate
> branches doesn't seem such a good idea in retrospect. We tried to do
> it for the master in 0.90 and it was just impossible to review/merge
> back... I don't really have a better solution in mind tho. Piecemeal
> patches kind of work sometimes, but let's all remind ourselves of the
> second 0.89...

Was the second 0.89 a failure? If I recall correctly, various people
ran it, found bugs, and reported them. We then fixed the bugs for the
third 0.89 release. Doing the broken one got us all testing a similar
set of bits (including some more adventurous users) and we used that
feedback to fix things up. 0.90.0 had a few bugs, but in general I'd
say 0.90.1 is a pretty nice release.

If anything I wish we'd done one more 0.89 release after the new
master got merged :) Even if it's broken, it's a valuable thing to
learn from.

I mentioned this interview to a few folks last week -- I thought it
was pretty interesting:


> On Mon, Feb 28, 2011 at 2:00 PM, Todd Lipcon <todd@cloudera.com> wrote:
>> 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

Todd Lipcon
Software Engineer, Cloudera

View raw message