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 2011/01/12 02:35:35 UTC
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
Posted by Jeremy Hanna <je...@gmail.com>.
+1 on starting a more predictable release cycle for Cassandra and doing more multi-node testing. I don't care at all about what version number it is.
On Jan 11, 2011, at 7: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:
> 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
Posted by Stu Hood <st...@gmail.com>.
> 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 <ee...@rackspace.com> wrote:
> On Thu, 2011-01-13 at 16:34 +0000, 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
> eevans@rackspace.com
>
>
Re: Time for 1.0
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2011-01-13 at 16:34 +0000, 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
eevans@rackspace.com
Re: Time for 1.0
Posted by Nick Telford <ni...@gmail.com>.
We could go the Microsoft route and call it Apache Cassandra 2011, or the
Ubuntu route and call it Apache Cassandra 11.08 (or whatever month the
release occurs in). The number itself is relatively unimportant.
I believe what Jonathan is proposing is a change to something that implies a
level of stability and production readiness, rather than the 0.x series,
which traditionally denotes software not yet ready for the wider world.
While I generally agree that the next release should be indicated as ready
for the world, I'd like to see the project's documentation updated; even if
it's just a mirror of the Riptano docs. In order to indicate that the
release is ready for the general public we need to have the resources
readily available to help them figure out what Cassandra is and how to use
Cassandra properly.
To summarise: +0.5
Regards,
Nick Telford
On 13 January 2011 14:14, Tim Estes <ti...@digitalreasoning.com> wrote:
> 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 <ee...@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
Posted by Tim Estes <ti...@digitalreasoning.com>.
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 <ee...@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
Posted by Daniel Lundin <dl...@eintr.org>.
On Wed, Jan 12, 2011 at 5:29 AM, Eric Evans <ee...@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
Posted by Eric Evans <ee...@rackspace.com>.
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
eevans@rackspace.com
Re: Time for 1.0
Posted by Jonathan Ellis <jb...@gmail.com>.
On Tue, Jan 11, 2011 at 8:29 PM, Eric Evans <ee...@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
Posted by Germán Kondolf <ge...@gmail.com>.
Can I vote with a "+100" ? :)
On Wed, Jan 12, 2011 at 12:42 PM, Eric Evans <ee...@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
> eevans@rackspace.com
>
>
--
//GK
http://twitter.com/germanklf
http://code.google.com/p/seide/
Re: Time for 1.0
Posted by Eric Evans <ee...@rackspace.com>.
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
eevans@rackspace.com
Re: Time for 1.0
Posted by Germán Kondolf <ge...@gmail.com>.
Will CQL be included in the 1.0 release?
// Germán Kondolf
http://twitter.com/germanklf
http://code.google.com/p/seide/
On 12/01/2011, at 01:29, Eric Evans <ee...@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. 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
> eevans@rackspace.com
>
Re: Time for 1.0
Posted by Robert Coli <rc...@digg.com>.
On Tue, Jan 11, 2011 at 8:29 PM, Eric Evans <ee...@rackspace.com> wrote:
> 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.
+1
=Rob
Re: Time for 1.0
Posted by Eric Evans <ee...@rackspace.com>.
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
eevans@rackspace.com
Re: Time for 1.0
Posted by Vijay <vi...@gmail.com>.
+1...
Regards,
</VJ>
On Tue, Jan 11, 2011 at 5:35 PM, Jonathan Ellis <jb...@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
Posted by Germán Kondolf <ge...@gmail.com>.
+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 <jb...@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
Posted by Jonathan Ellis <jb...@gmail.com>.
On Fri, Jan 14, 2011 at 11:24 AM, Ryan King <ry...@twitter.com> wrote:
> On Thu, Jan 13, 2011 at 7:32 PM, Jonathan Ellis <jb...@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
Posted by Ryan King <ry...@twitter.com>.
On Thu, Jan 13, 2011 at 7:32 PM, Jonathan Ellis <jb...@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
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Jan 13, 2011 at 1:46 PM, Ryan King <ry...@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
Posted by SriSatish Ambati <sr...@gmail.com>.
+1 On making unit tests & distributed tests robust
(with & without ec2)
Sri
On Thu, Jan 13, 2011 at 1:46 PM, Ryan King <ry...@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 <jb...@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
Posted by Ryan King <ry...@twitter.com>.
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 <jb...@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
Posted by Colin Taylor <co...@gmail.com>.
> 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
Posted by Courtney Robinson <sa...@live.co.uk>.
?+1
I see no reason why not. Since I've been using Cassandra (just over a year),
its been pretty stable*.
With all the improvements that have been made i say that more than warrants
a 1.0 release.
-----Original Message-----
From: Paul Brown
Sent: Wednesday, January 12, 2011 1:47 AM
To: dev@cassandra.apache.org
Subject: Re: Time for 1.0
+1.0
I'm not a committer, but I think a 1.0 is warranted, especially given the
number of folks who have the application in production. (In fact, 0.7 would
have made a reasonable 1.0.)
-- Paul
On 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:
> 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
Posted by Paul Brown <pa...@gmail.com>.
+1.0
I'm not a committer, but I think a 1.0 is warranted, especially given the number of folks who have the application in production. (In fact, 0.7 would have made a reasonable 1.0.)
-- Paul
On 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:
> 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
Posted by Jonathan Ellis <jb...@gmail.com>.
On Tue, Jan 11, 2011 at 7:35 PM, Jonathan Ellis <jb...@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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
On Tue, Jan 11, 2011 at 8:35 PM, Jonathan Ellis <jb...@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
>