cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject 0.6, 0.7, and the future
Date Wed, 17 Feb 2010 21:32:37 GMT
We're looking at branching 0.6 today and starting 0.7 work.

0.6 shaped up to be a really nice follow-up to 0.5, where we improved
just about everything while keeping the upgrade path super easy.  (We
changed the network around again, but no disk changes, so it's just
going to be shutdown-and-restart.)  Client APIs are 100% compatible,
with the exception of get_key_range, which we had tagged as deprecated
in 0.5 for removal in the next release.

So to recap recent history, we went from 0.4 to 0.5 to 0.6 without
major client level API changes.  I think that is an excellent record
for where we were when we were releasing 0.4.

0.7 is probably going to be a little more painful, after which we hope
to have things stable for another few releases, at the least.

Tickets currently tagged 0.7 are here:

They are a good mix of
 - fundamental internals changes that we have been putting off so far
(#674, #16, and friends)
 - stuff that we really really want to make ops better (#44)
 - pie in the sky new features (#749)
 - incremental improvements to what we already have

The primary pain source from the client perspective is going to be the
internals changes, particularly moving row keys from String to byte[].
 But it's a change we've know need need to make and I think it's time
to bite the bullet.

Also, if we were to execute on all the tickets there, 0.7 would be
this huge monster release that will take like 6 months to get out.  i
think that's too long.  Shipping is feature #1 at this stage, I'm
really scared of biting off too much and losing weeks or months to

So what I'd like to propose is making 0.7 primarily about the
internals changes and push for high-level queries in 0.8, where both
of those hit our usual ~3 month release cycle.  I don't think it makes
sense to do those the other way around; introducing new APIs that we
already know we need to break just seems mean. :)


View raw message