cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5156) CQL: loosen useless versioning constraint
Date Tue, 15 Jan 2013 15:52:12 GMT


Eric Evans commented on CASSANDRA-5156:

# C* 1.1 and 1.2.0 both accept a 3 number version and there is some client code out there
that sends a 3 number version when connecting. So changing to 2 number version might bring
a small amount of confusion/unpleasantness and that's just not worth it imo.

I don't think it would be too confusing to drop Z from the spec, and accept-but-silently-ignore
it from drivers setting the version.  It already accepts a partial version anyway, doesn't

# I think we might very well end up with quite a large amount of revisions of/additions to
the CQL3 spec (because there is a lot of opportunity to improve it without breaking backward
compatibility). And I like the idea of increasing the Z number for little things and bumping
Y for more important ones (or when we had "enough" of Z bumps), so we don't end up with a
3.54 version (to quote Linus, "the real reason is just that I can no longer comfortably count
as high as 40"). Note that bumping Y or Z would be largely arbitrary and non-semantic but
I don't see the harm in that.

I'm a big fan of utilizing a version number like this to communicate/set expectations with
users.  Realistically, I don't think you can do this effectively if you arbitrarily assign

> CQL: loosen useless versioning constraint
> -----------------------------------------
>                 Key: CASSANDRA-5156
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Trivial
>             Fix For: 1.2.1
>         Attachments: 5156.txt
> So far the CQL doc says the CQL language follows Meaning that a version
is X.Y.Z where:
> * X is the major version and denotes backward incompatible changes
> * Y is the minor version and denotes backward compatible changes
> * Z is the patch version and denotes backward *and* forward compatible changes, i.e.
change to the implementation.
> Now I don't think for CQL we have much use of the patch version. Not that knowing when
implementation fixes have been done is not useful but:
> # The Cassandra version number already kind of cover that.
> # While a patch version would be more precise in that it would only concern CQL3 related
changes, I have no illusion on our capacity in maintaining such patch version accuratly (and
frankly, I don't blame us).
> So instead of keeping a number that will end up having no usefulness whatsoever, I suggest
that we either:
> # remove it and have CQL3 version being just major and minor.
> # use that latter number as a sub-minor version, i.e. a version that only
> # denotes backward compatible changes, not forward ones. We would then bump the two last
digit at our discretion, to denote some form of "importance" of the changes.
> I don't care much about which of the two we end up doing, but since we already have a
3 numbers version and since I kind of like the idea of having two numbers to convey a sense
of importance of the changes, I'm attaching a patch for the 2nd solution.
> Note that the patch removes the changes section from the doc, but that's because I think
it's useless in it's current form (on top of being inaccurate).  I do plan on adding a new
changes section that lists changes between CQL minor version as soon as we have some of those.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message