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 Wed, 02 Mar 2011 22:39:39 GMT
On Tue, Mar 1, 2011 at 9:34 AM, Jean-Daniel Cryans <jdcryans@apache.org> wrote:
> That's a pretty good interview, thanks for sharing! Soooo is our idea
> of using odd numbered release as DRs bad? Should we just release more
> often like every 3 months? I vote Stack as our Linus!

I think there are basically two ways of going about this, and it
depends on a philosophical choice:

The old Linux way (odd-even stable):
- users knew that 2.3.x and 2.5.x were development series and wouldn't
be stable.
- distros and almost every user ran off even-numbered releases
- odd-number releases might be fairly broken
- there's some pre-release decision that the release will be an
even-numbered "stable"/"good" release as opposed to a odd-numbered
dev-quality release.

This is basically what we did for 0.89.x. I thought it worked fairly well.

The new Linux way ("good vintages and long-lived branches"):
- new releases are done time-based and there's no guarantee of any
particular stability level
- users rely on some documentation somewhere to know what a "good vintage" is
- either distributors or some section of the community steps up to
designate some good vintage to be a long-lived branch, where critical
bugfixes will get backported. eg 2.6.18 was a good vintage, 2.6.32 is
- the "good vintages" aren't decided at release-time, but rather
retroactively - ie we just release on the train model, and at some
point someone takes one of those trains that "seems pretty good" and
starts stabilizing it up.

The interesting thing about the "good vintages" model is that you
don't follow the usual policy of a bugfix having to be backported to
all releases in between trunk and the vintage. Let's pretend we had
0.90, 0.91, 0.92, 0.93, and 0.94, where 0.90 was the "good vintage"
release. If we commit a fix to trunk in today's Apache model, we'd
also have to commit to ALL of those releases back through 0.90, which
is a giant pain.

The other interesting (and more philosophical) bit is that the "good
vintage" model serves to separate the developers from the users, in
that the users are expected to be several releases back on a stable
branch. This can be both good and bad - bad because it takes a while
for a new feature to trickle to a user, good because changes go
through a few layers of vetting for bugs before they hit users.

Any thoughts?

Todd Lipcon
Software Engineer, Cloudera

View raw message