incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan King <r...@twitter.com>
Subject Proposal: fixed release schedule
Date Thu, 13 Jan 2011 22:32:56 GMT
I think many believe that shipping 0.7 took longer than it should.
Rather than going into why that happened, I'd like to propose a better
way to move forward that will hopefully allow us to ship on a more
predictable schedule. This proposal is heavily influenced by the
google chrome release process:

http://www.scribd.com/doc/46659928/Chrome-Release-Cycle-12-16-2010'

..which is heavily influenced by how large websites deploy code
(everyone close to trunk, hide incomplete changes behind configuration
flags, etc.)

I'm not saying we should adopt this process as-is, but some aspects of
it seem like they would be valuable–

# Fixed schedule

We should set a fixed schedule and stick to it. Anything features not
ready at branch time won't make it and will be disabled in the stable
branch.

# Trunk-first

Everyone on chrome commits to trunk first. I think the important
change we could make is to keep everyone closer to trunk. We spend a
good deal of effort back-porting patches between major versions. I
think we should make the major versions less different. This would
mean letting them live for shorter amounts of time and possibly making
them bugfix only. Currently we add new features in stable branches,
but I think if we made the major release schedule more predictable
people would be more comfortable with letting their new feature wait
until the next major version.

We should be more liberal about committing things to trunk early and
iterating on them there (rather than iterating on them in patches). If
the features are unstable we can either hide them behind configuration
flags or remove them when we cut a stable branch.

# Automate all tests

I think the only way that we can keep people close to trunk and stay
stable is to build automated tests for *everything*. All code should
be exercised by thorough unit tests and distributed black-box tests.
Every regression should get a test.


Chrome has a 6 week cycle. I think ours would be more like 4 months
for major releases.

Whatever we do, I think the schedule needs to be more predictable,
which means that the contents of each release will be less predictable
(since its "whatever's ready at the appointed time"). Like the Chrome
presentation mentioned the idea isn't raw speed, but predictable
release schedules.

Feedback please.

-ryan

Mime
View raw message