Re: Time for 1.0
On Thu, 2011-01-13 at 19:20 -0800, Jonathan Ellis wrote: -0 I've said it elsewhere, but the only reason to fuss about a 1.0, is that it is loaded with special meaning. Right: that's what we should be doing. Up to and including the start of 0.6 you almost had to have a committer on staff to run Cassandra in production. That's much less true at the end of 0.6 and the start of 0.7. (As Paul says, I think we could have legitimately called 0.7, 1.0, but better late than never.) As we've already seen in this thread, your criteria for a 1.0 isn't universally accepted, and neither is your assessment that Cassandra meets it. Don't get me wrong, I'm not saying that your criteria is incorrect. I'm saying that 1.0 has a special yet different meaning for everyone. Christening a 1.0 will send a message, and many will receive the wrong one. It's also worth pointing out that dev@ is a pretty narrow audience, I'm guessing we'll see even greater variation elsewhere. I'd rather drop the leading the 0 and continue to number releases sequentially the way we have. If our 1 versioning is signaling a lack of readiness, and if = 1 is a necessary gate, then 8.0 should work equally as well. Better in fact, 8 times better! This defeats the purpose of changing the numbering, since by calling it 8.0 you're saying all those other major releases we did were just as 1.0 production ready as this one, so you're signaling nothing at all. Which I think was your somewhat cynical point. :) It would be my intention to say, the 0 never meant anything, and this is our 8th release, which I think is better than saying, this is our first release. FWIW, the other suggestions (date-based versions like 2011.01, etc), work equally as well for me. :) -- Eric Evans eev...@rackspace.com
Re: Time for 1.0
On Thu, Jan 13, 2011 at 7:32 PM, Jonathan Ellis jbel...@gmail.com wrote: ... In other words, at some point you have so many production users that it's silly to pretend it's ready for 1.0. I'd say we've passed that point. Did you mean to say silly to pretend it's *not* ready for 1.0? Otherwise, I don't understand. I'm on board with this, to the point that Riptano is hiring a full-time QA engineer to contribute here. Like I said at the outset, I don't care so much about what the version is called as long as the quality continues to improve. -ryan
Re: Time for 1.0
On Fri, Jan 14, 2011 at 11:24 AM, Ryan King r...@twitter.com wrote: On Thu, Jan 13, 2011 at 7:32 PM, Jonathan Ellis jbel...@gmail.com wrote: ... In other words, at some point you have so many production users that it's silly to pretend it's ready for 1.0. I'd say we've passed that point. Did you mean to say silly to pretend it's *not* ready for 1.0? Otherwise, I don't understand. Yes, that is what I meant. :) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Time for 1.0
+1 On making unit tests distributed tests robust (with without ec2) Sri On Thu, Jan 13, 2011 at 1:46 PM, Ryan King r...@twitter.com wrote: 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
Re: Time for 1.0
On Wed, Jan 12, 2011 at 5:29 AM, Eric Evans eev...@rackspace.com wrote: I'd rather drop the leading the 0 and continue to number releases sequentially the way we have. If our 1 versioning is signaling a lack of readiness, and if = 1 is a necessary gate, then 8.0 should work equally as well. Better in fact, 8 times better! +1 for semantic versioning http://semver.org/. It may not be perfect (whatever that means) but at least it has a common, [well] defined meaning. As for `due diligence`, that's a fine codename for the next release. :)
Re: Time for 1.0
Speaking more for an organization that works with a lot of external parties using Cassandra (that don't necessarily develop on it), I think the pivot to 1.0 makes better sense. A lot of the world is still coming to know Cassandra vs. any other NoSQL type solution. In that environment, I think the production grade validation is important. to the point below... I'd submit that sometimes you jump for 8.0 to 10.0. Then we just move the decimal. Really- I'm sure that groups can make the shift and get it. +1 to Jonathan's original suggestion. -- Tim Estes CEO Digital Reasoning Systems On Jan 13, 2011, at 1:58 AM, Daniel Lundin wrote: On Wed, Jan 12, 2011 at 5:29 AM, Eric Evans eev...@rackspace.com wrote: I'd rather drop the leading the 0 and continue to number releases sequentially the way we have. If our 1 versioning is signaling a lack of readiness, and if = 1 is a necessary gate, then 8.0 should work equally as well. Better in fact, 8 times better! +1 for semantic versioning http://semver.org/. It may not be perfect (whatever that means) but at least it has a common, [well] defined meaning. As for `due diligence`, that's a fine codename for the next release. :)
Re: Time for 1.0
In that environment, I think the production grade validation is important. A bump in version number does not give you production grade validation: in fact, it is the other way around. I'm -1 on going to 1.0 for the next release. On Thu, Jan 13, 2011 at 9:06 AM, Eric Evans eev...@rackspace.com wrote: On Thu, 2011-01-13 at 16:34 +, Nick Telford wrote: ...or the Ubuntu route and call it Apache Cassandra 11.08 (or whatever month the release occurs in). The number itself is relatively unimportant. And while we're at it, how about a codename in adjective-animal form? Some suggestions: * Funky Monkey * Flatulent Platypus * Leaky Walrus * Ballsy Beaver * Salty Porcupine I could do this all day. :) -- Eric Evans eev...@rackspace.com
Re: Time for 1.0
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
Re: Time for 1.0
On Tue, Jan 11, 2011 at 8:29 PM, Eric Evans eev...@rackspace.com wrote: On Tue, 2011-01-11 at 19:35 -0600, 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: 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. -0 I've said it elsewhere, but the only reason to fuss about a 1.0, is that it is loaded with special meaning. Right: that's what we should be doing. Up to and including the start of 0.6 you almost had to have a committer on staff to run Cassandra in production. That's much less true at the end of 0.6 and the start of 0.7. (As Paul says, I think we could have legitimately called 0.7, 1.0, but better late than never.) I'd rather drop the leading the 0 and continue to number releases sequentially the way we have. If our 1 versioning is signaling a lack of readiness, and if = 1 is a necessary gate, then 8.0 should work equally as well. Better in fact, 8 times better! This defeats the purpose of changing the numbering, since by calling it 8.0 you're saying all those other major releases we did were just as 1.0 production ready as this one, so you're signaling nothing at all. Which I think was your somewhat cynical point. :) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Time for 1.0
On Thu, Jan 13, 2011 at 1:46 PM, Ryan King r...@twitter.com wrote: 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. Those of us running production clusters jumps out at me here. Being production-ready is THE major thing that 1.0 is supposed to signal; the other things I mentioned (features, upgrade path, etc) are signals that can help determine that, but actual production clusters is the real story. In other words, at some point you have so many production users that it's silly to pretend it's ready for 1.0. I'd say we've passed that point. 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 Right. 1.0 shouldn't mean it does everything we can think of, it means it is reasonably feature complete and stable for a given purpose, then you add features and expand your problem domain and so forth in future versions. I think that being able to put a check mark by every single item on that 2009 list and then some is a very strong signal that we've reached a milestone, even though we can now think of more things we want. Projects that reserve 1.0 for some abstract vision of unattainable perfection frustrate me. 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). I'm on board with this, to the point that Riptano is hiring a full-time QA engineer to contribute here. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Time for 1.0
On Wed, 2011-01-12 at 07:55 -0300, Germán Kondolf wrote: Will CQL be included in the 1.0 release? CQL 1.0 will be the next release. :) -- Eric Evans eev...@rackspace.com
Re: Time for 1.0
Can I vote with a +100 ? :) On Wed, Jan 12, 2011 at 12:42 PM, Eric Evans eev...@rackspace.com wrote: On Wed, 2011-01-12 at 07:55 -0300, Germán Kondolf wrote: Will CQL be included in the 1.0 release? CQL 1.0 will be the next release. :) -- Eric Evans eev...@rackspace.com -- //GK http://twitter.com/germanklf http://code.google.com/p/seide/
Time for 1.0
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
Re: Time for 1.0
+1 days ago I was wondering about the gap between 0.7 and a future 1.0, the answer is just a few more enhancements like you said. :) Excellent news :) // Germán Kondolf http://twitter.com/germanklf http://code.google.com/p/seide/ // @i4 On 11/01/2011, at 22:35, 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
Re: Time for 1.0
On Tue, Jan 11, 2011 at 7:35 PM, Jonathan Ellis jbel...@gmail.com wrote: The list-- Through a copy/paste error I left out the first one: Increment/decrement: done :) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Time for 1.0
User documentation: done (http://www.riptano.com/docs) Apologies if this has been covered elsewhere but, is this a permanent home? Is there to be mirror on the official site? Surely if the project itself doesn't have user documentation then the milestone has not been reached by the project. I understand the motivation and it is Riptano's right of course, but the project still needs its own comprehensive user documentation. cheers Colin.
Re: Time for 1.0
On Tue, 2011-01-11 at 19:35 -0600, 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: 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. -0 I've said it elsewhere, but the only reason to fuss about a 1.0, is that it is loaded with special meaning. To impart some vague notion of readiness on people who should be paying less attention to a number, and doing more due diligence. Feels like pandering to me, or cargo-culting. I'd rather drop the leading the 0 and continue to number releases sequentially the way we have. If our 1 versioning is signaling a lack of readiness, and if = 1 is a necessary gate, then 8.0 should work equally as well. Better in fact, 8 times better! -- Eric Evans eev...@rackspace.com
