cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Goffinet ...@chrisgoffinet.com>
Subject Re: 0.6, 0.7, and the future
Date Thu, 18 Feb 2010 03:56:27 GMT
+1 from Digg

-Chris

On 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:
> 
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310865&fixfor=12314533
> 
> 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. :)
> 
> -Jonathan


Mime
View raw message