First, let's be clear about our priorities here. While backwards compatibility is an important consideration, it is not a guarantee we have made for CQL, nor should we at this stage in its development.
As Eric points out, we have made breaking changes deliberately before, because updating the language to add missing functionality made clear where we'd gotten something wrong. Expecting anything else from a partially finished language is totally unrealistic.
Keep in mind as well that maintaining deprecated features indefinitely is a resource sink that we can ill afford. We have a relatively small set of active developers, and time spent working around code supporting obsolete features, perhaps fixing regressions caused by keeping it alive, is time we can ill afford. Unlike Thrift, where methods live in relative isolation in CassandraServer, everything in the CQL parser and QueryProcessor is intertwined. So there is a higher price to pay than you may realize.
What should you do if backwards compatibility is your highest priority? You should absolutely be using the Thrift API, where we have guaranteed 100% backwards compatibility. There are legitimate reasons to be a CQL early adopter (primarily ease of driver implementation, which I assume is what drove your decision to go that route for Node.js) but backwards compatibility is not one of them.
Will we get to a point eventually where we can say "100% backwards compatibility in CQL from here on out?" Absolutely. But we're just not there yet. Fortunately, there aren't many production CQL installations yet, so, with all due respect for your situation, we can fix mistakes and add features without too much pain yet, compared to the pain from leaving them festering (and not adding features like this one).
But the longer we go before making necessary changes and finishing things, the more painful that will get. So, to Eric's point, better to make these changes now – which I've been promising in public since at least Cassandra SF, so I don't think it's valid to cry end-of-release foul – than to make them for the 1.2 transition, when presumably more people will have deployed on CQL.
This is a long way of saying that as a general principle, dropping blanket -1s on CQL changes to force compatibility-by-stagnation is irresponsible at this point.
Now, to the specifics of your objections:
pre-emptive -1 on supporting [.. notation] for one more version and then removing it
We could probably stretch this out to two releases, but as I've explained, we shouldn't be committing to "forever". We need to be able to fix misfeatures without paying the tax of keeping deprecated interfaces around indefinitely.
The two reasons you gave are subjective
Let me elaborate. We're not actually removing functionality here. The new-style definition of
CREATE TABLE foo (
key <type1> PRIMARY KEY,
) WITH COMPACT STORAGE
gives you the same freedom of using arbitrary column names as an old-style declaration with a comparator of type2. The difference is, this definition allows CQL queries to know how to turn the column name into a resultset value, allowing it to be used in more flexible WHERE clauses than .., as well as allowing use in paging across multiple rows (necessary for wide-row map/reduce support).
So, we're not taking away the flexibility to use column names at run time for non-composite columns; just requiring that if you want to use a CF in a dynamic, wide-row way, you tell us about it so we can support you appropriately. (Knowing when a CF is "wide row oriented" also opens up new optimization possibilities, from simple ones like skipping the row-level bloom filter to fancier ones like
How about we leave them the way they are BECAUSE USERS EXPECT IT TO BE THAT WAY?
Hmm. I'm not sure if you misread what he said and thought he's changing it to case-sensitive, or if you think case-sensitive is how it behaves now. Or maybe something else entirely.
Currently, column names are case insensitive, (see QueryProcessor.getColumnNames), and so are row keys (WhereClause.extractKeysFromColumns). But, right now you're allowed to define a CF with columns "a" and "A" but no way to disambiguate at SELECT time which one you actually want. So, the important part of what Sylvain is talking about here is "... unless they are enclosed in single or double quotes," i.e., to allow you to write SELECT "A" to be explicit about which one you want. I don't see this breaking anything.
(I don't think you're saying that users expect things to be case-sensitive, because CQL has never worked that way, but just in case, I'll also point out that both SQL and the CLI treat column names case insensitive, so I'd be very surprised if many users agree that sensitive is "expected.")