Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> HBase releases...

Copy link to this message
Re: HBase releases...
I just wrote in parallel response to Jesse that I am not a big fan of
time based releases :)

The way you describe it it makes sense, though.

o we'd branch at given intervals (once a week/month/quarter/whatever)
o some releases will turn out to be good ones, users could standardize on those

o we would only provide updates in a form of a new release, or maybe a dev and stable release
Might be hard to get bigger features in that way; although Linux
manages that with merge windows.
Seems like this'd be a big shift. Hence my softer approach to just change
a bit what 'it feels right' means.

-- Lars
----- Original Message -----
From: Todd Lipcon <[EMAIL PROTECTED]>
To: dev@hbase.apache.org
Sent: Tuesday, October 11, 2011 11:02 PM
Subject: Re: HBase releases...

I was discussing this with a few other contributors a while back. In
my mind there are two ways to do it:

a) feature based releases that we test the crap out of and decide are
stable. We can't really do this more than once a year, I don't think.
b) time based releases where we make few guarantees beyond "it appears
to work". We assume that once a year or so, major users and
distributors latch on to one of these that feels good, and start
maintaining it as a stable/maintenance series.

B is the Linux model. No one in their right mind runs the latest
kernel.org in production - but certain vintages of kernel gather
enough folks around them, pick up a stable maintainer, etc, and after
a while become pretty rock solid. For example, 2.6.18 and 2.6.32 seem
to be popular kernel vintages.

I'm personally of the mind that B is the more reasonable model. Keeps
a release train ticking all the time, allows experimental users to get
new features fast, and avoids the burden of feeling that any release
we do has to be perfect. It's also often hard to say what "vintage"
will be good until it's been out in the wild for a little while - for
example, the 0.89.20100621 dev release turned out to be pretty decent
despite being branded as a dev release. The later releases in that
series had some more major problems.

The risk with the "B" model is that everyone might end up on different
versions, making it very hard to support the user community, etc. This
might be partially ameliorated by some clear descriptions on the
download/release pages which delineate which are stable/recommended
releases and which are just time-based.

On Tue, Oct 11, 2011 at 10:42 PM, Jesse Yates <[EMAIL PROTECTED]> wrote:
> 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?

Todd Lipcon
Software Engineer, Cloudera