You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2010/02/17 22:32:37 UTC
0.6, 0.7, and the future
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
Re: 0.6, 0.7, and the future
Posted by Ryan King <ry...@twitter.com>.
On Wed, Feb 17, 2010 at 1:32 PM, Jonathan Ellis <jb...@gmail.com> 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. :)
I agree. Let's push new features back. From our perspective,
performance, reliability and operability are more important than new
features.
-ryan
Re: 0.6, 0.7, and the future
Posted by Vijay <vi...@gmail.com>.
+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
>
>
Re: 0.6, 0.7, and the future
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Feb 18, 2010 at 2:49 PM, Ryan King <ry...@twitter.com> wrote:
> On Thu, Feb 18, 2010 at 11:45 AM, Anthony Molinaro
> <an...@alumni.caltech.edu> wrote:
>> +1
>> (although I'm dreading the export from old sstables into new sstables,
>> any ideas on how fast that might be?, and I guess any idea if a tool
>> for doing this will be provided, or is it sstable2json and json2sstable?)
>
> I'm not entirely sure of the plans here, but I think the idea is that
> any release of cassandra going forward is going to have to be able to
> deal with multiple versions of SSTable formats.
>
> I propose that when we change the format in a release we don't
> proactively rewrite the tables– just keep the old tables as-is and
> only write with the new format when we're already going to be writing
> a table (flushing or compacting). That way you can have a smooth
> upgrade if you want, or if you want to force the upgrade, you just
> trigger a major compaction.
This is my preference as well. We'll see if we can pull it off. :)
-Jonathan
Re: 0.6, 0.7, and the future
Posted by Ryan King <ry...@twitter.com>.
On Thu, Feb 18, 2010 at 11:45 AM, Anthony Molinaro
<an...@alumni.caltech.edu> wrote:
> +1
> (although I'm dreading the export from old sstables into new sstables,
> any ideas on how fast that might be?, and I guess any idea if a tool
> for doing this will be provided, or is it sstable2json and json2sstable?)
I'm not entirely sure of the plans here, but I think the idea is that
any release of cassandra going forward is going to have to be able to
deal with multiple versions of SSTable formats.
I propose that when we change the format in a release we don't
proactively rewrite the tables– just keep the old tables as-is and
only write with the new format when we're already going to be writing
a table (flushing or compacting). That way you can have a smooth
upgrade if you want, or if you want to force the upgrade, you just
trigger a major compaction.
-ryan
Re: 0.6, 0.7, and the future
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
+1
(although I'm dreading the export from old sstables into new sstables,
any ideas on how fast that might be?, and I guess any idea if a tool
for doing this will be provided, or is it sstable2json and json2sstable?)
On Wed, Feb 17, 2010 at 07:56:27PM -0800, Chris Goffinet 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
>
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: 0.6, 0.7, and the future
Posted by Chris Goffinet <cg...@chrisgoffinet.com>.
+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
Re: 0.6, 0.7, and the future
Posted by Jonathan Ellis <jb...@gmail.com>.
On Wed, Feb 17, 2010 at 5:26 PM, David Strauss <da...@fourkitchens.com> wrote:
> How dependent are the 0.8 high-level queries on the 0.7 internal changes?
It will definitely be affected by the String -> byte[] change with
everything else. It also may benefit from being able to have more
levels of subcolumns than the 1 we offer now. Hard to say since we
don't really know what it's going to look like yet.
-Jonathan
Re: 0.6, 0.7, and the future
Posted by David Strauss <da...@fourkitchens.com>.
On 2010-02-17 21:32, Jonathan Ellis wrote:
> 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. :)
How dependent are the 0.8 high-level queries on the 0.7 internal changes?
--
David Strauss
| david@fourkitchens.com
Four Kitchens
| http://fourkitchens.com
| +1 512 454 6659 [office]
| +1 512 870 8453 [direct]
Re: 0.6, 0.7, and the future
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2010-02-17 at 15:32 -0600, Jonathan Ellis wrote:
> 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 think this makes sense. +1
--
Eric Evans
eevans@rackspace.com