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. -ryan On Tue, Jan 11, 2011 at 5:35 PM, Jonathan Ellis <jbel...@gmail.com> 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: > http://www.mail-archive.com/cassandra-user@incubator.apache.org/msg01446.html > > 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; > https://issues.apache.org/jira/browse/CASSANDRA-1427 is open to > improve it > > Decommission: done > > Map/reduce support: done > > ColumnFamily / Keyspace definitions w/o restart: done > > Design documentation: started at > http://wiki.apache.org/cassandra/ArchitectureInternals > > 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 > https://issues.apache.org/jira/browse/CASSANDRA-1969 and > https://issues.apache.org/jira/browse/CASSANDRA-1956) > > Bulk delete (truncate): done > > I would add, > > User documentation: done (http://www.riptano.com/docs) > > 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 > (https://issues.apache.org/jira/browse/CASSANDRA-1015) > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
