[
https://issues.apache.org/jira/browse/CASSANDRA-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13553682#comment-13553682
]
Sylvain Lebresne commented on CASSANDRA-5156:
---------------------------------------------
bq. and Z is for everything else (typos, breakfixes, etc)
You're right, the "should be forward compatible" was a wrong interpretation of
mine. In any case that only means that we should indeed do the validation
change to the SemanticVersion class the patch contains.
bq. I'm not sure I grok what you mean wrt 2 and 3.
Didn't realized I had screwed the formatting, 2 and 3 are supposed to be the
same point.
Basically, and to rephrase, what I'm saying is that the difference between
minor and patch of http://semver.org is probably too subtle for our use case:
realistically we won't be able to respect it, and, as you say, it doesn't offer
much value. All we probably want to respect as far as semantic goes is that
only major version will induce backward incompatible changes (and that any
change to the language will induce a version change but that goes without
saying). So, I think we agree on that.
So all the attached patch does is to 1) fix the "bug" in the SemanticVersion
class of assuming a "patch" version bump imply forward compatibility and 2)
don't pretend in the doc we follow http://semver.org/ to the letter.
Now if we do not make a semantic difference between Y and Z, keeping only Y is
an option indeed, as you say. But I'm saying I have a slight preference for
keeping both Y and Z for the following 2 reasons:
# 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 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.
> 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
