[
https://issues.apache.org/jira/browse/CASSANDRA-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13553949#comment-13553949
]
Sylvain Lebresne commented on CASSANDRA-5156:
---------------------------------------------
bq. I'm a big fan of utilizing a version number like this to communicate/set
expectations with users
Sure, me too, and I would say that what I'm suggesting is somewhat better at it
:).
The only strong expectation the version number will set is that major bumps
won't break backward compatibility. Whether Z is here or not doesn't change
that at all.
But if you drop Z, then Y bumps really can only mean "some" change that don't
break backward compatibility and you don't convey anything more.
Now different people have different expectations concerning version numbers,
but I'm pretty sure that for most people 3.0.1 communicate the idea of a minor
increment over 3.0.0 and so probably additions/changes that they can check
"when they have time", while 3.1.0 communicate the idea of more substantial
change, something that is probably worth checking out. I think that this is a
useful thing to communicate. When I said "arbitrary", I meant that there's
bound to be some subjectivity in deciding what qualify as an important or a
minor addition. But it's ok, it's still useful information imo.
> CQL: loosen useless versioning constraint
> -----------------------------------------
>
> Key: CASSANDRA-5156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5156
> 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 http://semver.org/. 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: http://www.atlassian.com/software/jira
