incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan King <>
Subject Re: Time for 1.0
Date Thu, 13 Jan 2011 21:46:53 GMT
I'm a -1 on naming the next release 1.0 because I don't think it has
the quality that 1.0 implies, but to be honest I don't really care
that much. The version numbers don't really effect those that of use
that are running production clusters. Calling it 1.0 won't make it any
more stable or faster.

Also, before we say that "everything people want in 1.0 is done",
perhaps we need to do that survey again. A lot of people have joined
the community since 0.5 days and their needs should probably be
considered in this situation. Also, those of use who've been around
have new things we care about. Of course this will always be true and
at some point we need to draw a line in the sand and put the 1.0 stamp
on it– I just feel that that time has not come yet (but, like I said I
don't really care that much because it won't affect me).

Regardless of what we call the next major release there's at least 2
things I'd like to see happen:

1. make the distributed test suite more reliable (its admittedly flaky
on ec2) and flesh it out to include all distributed functionality. We
shouldn't run a distributed system without distributed tests. We'll
work on the flakiness, but we need people to write tests (and
reviewers to require tests).
2. I think we should change how we plan releases. I'll send another
email about this soon.


On Tue, Jan 11, 2011 at 5:35 PM, Jonathan Ellis <> wrote:
> Way back in Nov 09, we did a users survey and asked what features
> people wanted to see.  Here was my summary of the responses:
> Looking at that, we've done essentially all of them.  I think we can
> make a strong case that our next release should be 1.0; it's
> production ready, it's reasonably feature-complete, it's documented,
> and we know what our upgrade path story is.
> The list--
> Load balancing: basics done;
> is open to
> improve it
> Decommission: done
> Map/reduce support: done
> ColumnFamily / Keyspace definitions w/o restart: done
> Design documentation: started at
> Insert multiple rows at once: done
> Remove_slice_range / remove_key_range: turned out to be a *lot* harder
> than it looks at first.  Postponed indefinitely.
> Secondary indexing: done
> Caching: done (with some enhancements possible such as
> and
> Bulk delete (truncate): done
> I would add,
> User documentation: done (
> Large row support: done
> Improved replication strategies and more sophisticated ConsistencyLevels: done
> Efficient bootstrap/streaming: done
> Flow control: done
> Network-level compatibility between releases: scheduled
> (
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support

View raw message