hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Yates <jesse.k.ya...@gmail.com>
Subject Re: HBase releases...
Date Wed, 12 Oct 2011 05:42:02 GMT
I see a couple other dimensions as well, and mostly they revolve around the
user community.

If we can release more frequently, with truly stable releases, then more
people will be more likely to run clusters with codebases that are closer to
trunk. Therefore they will have more benefits like bug fixes and performance
increases without the worry that they are running unstable/buggy code.
However, there is a big 'if' here - if we can make sure that the builds that
go out frequently are really rock solid.

I think in the past we have had a good track record with putting out stable
releases, especially given the amount of testing that people in dev are
doing on real, big clusters (thanks everyone!).

This then presents the problem of maintaining a _ton_ of branches compounded
by the difficulty of adding in a sweeping feature (coprocessor-style). That
was a huge pain to integrate (awesome job getting it in - super excited to
see .92 go out with it).

Lars, are you proposing that we stick to more of a time based schedule
rather than a 'it feels right' mechanism? I worry that we can get caught in
between making some really good changes and then having essentially a
half-baked release come out. That will hurt credibility with end users if we
say yeah, you could you release "x", but you might as well wait till "x+1"
cause some really good stuff is coming in then. Then why did we take the
time to release it in the first place?

As a middle ground, maybe we can look at the number of major and minor
updates since the last branch and drop a cut a new release when it exceeds
some threshold. For the first couple of iterations, this would be a flexible
limit until we find what works and makes sense to maintain. Maybe this also
means developing something like "x minor changes = 1 major change, and we
release every Y major change" kind of formula. After that, we can use a
community voting process to bump the limits for exceptional cases.

This ensures that we don't do pointless releases, but instead put out
versions and still minimizes the pain involved in maintaining multiple
branches.

What do you think?

-Jesse Yates

On Tue, Oct 11, 2011 at 10:22 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> HBase 0.90 was released Jan 2011. By the time HBase 0.92 is released it
> will probably be close to
> a year between stable releases.
>
> Should we try to have more frequent, smaller releases? Maybe 3-4 a year.
> For example I would almost say that the performance enhancements from the
> Facebook guys would
> warrant a new (performance) release "shortly" after 0.92.
>
> That would hopefully reduce the time and effort needed to stabilize the
> releases, at the expense of having to
> maintain two or even three branches in addition to trunk that people would
> still be actively using.
>
> Thoughts?
>
> -- Lars
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message