incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan King <>
Subject Re: 0.6, 0.7, and the future
Date Wed, 17 Feb 2010 21:39:54 GMT
On Wed, Feb 17, 2010 at 1:32 PM, Jonathan Ellis <> wrote:
> 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
> that.
> 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. :)

I agree. Let's push new features back. From our perspective,
performance, reliability and operability are more important than new


View raw message