incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijay <vijay2...@gmail.com>
Subject Re: 0.6, 0.7, and the future
Date Thu, 18 Feb 2010 19:13:42 GMT
+1

Regards,
</VJ>




On Wed, Feb 17, 2010 at 7:56 PM, Chris Goffinet <cg@chrisgoffinet.com>wrote:

> +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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message