[
https://issues.apache.org/jira/browse/CASSANDRA-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554936#comment-13554936
]
Sylvain Lebresne commented on CASSANDRA-5156:
---------------------------------------------
bq. Z (patch-level) was reserved for non-normative changes, even if it resulted
in a normative change to the document
I understand the intent, but let's be honest on the fact that "the document" is
closer to a documentation of the implementation than a proper formal
specification that drives said implementation (one may wish it was different
but let's keep rants about how it should have been for other venue). And yes,
distinctions can be made between a language and it's implementation, and even
to some extent between a language intent and the document specifying it. But
realistically, I don't think that trying to have the version number reflect
such subtleties is/will be practical for us.
What we should do I think is bumping the CQL version every time we change
something that have a user visible impact and be careful at properly
documenting said changes. And of course be careful at not breaking backward
compatibility (but we all agree on that I'm sure). I think that for the most
part that's what users expect, and doing that properly (the documentation in
particular) will already require some effort.
Now, using a version of the form X.Y would definitively be enough to do what's
above. But as a user, I don't always have the time to look at the details of
what's new in every version of software/language I use. So I appreciate it when
developers of said software use the version number to provide their estimation
of how "important" a new version is so I can very quickly judge whether I want
to look at the changelog now or later (or ever). As a user, I understand such
"importance estimation" is bound to be somewhat subjective but I still
appreciate it and in fact it's common enough that I somewhat expect it. I don't
think I'm the only one and so for CQL, I'd prefer keeping a version of the form
X.Y.Z and bumping Y or Z based on our estimation of the importance of (backward
compatible) changes going versus only having X.Y and always bumping Y (and I
certainly don't think the former convey *less* meaning than the latter).
But let's be concrete if possible. We should start thinking about shipping
1.2.1 soon. At a minimum I really think CASSANDRA-4936 should get in, though
there is no real reason not to get things like CASSANDRA-4927 in too. For that,
I want to 1) bump the CQL version because those have user visible impact and 2)
document clearly said version bump in
http://cassandra.apache.org/doc/cql3/CQL.html. If it was just me, I'd call the
resulting version 3.0.1 cause those are relatively minor additions. The main
question to resolve in this issue is: is there a problem with that? And if so,
what is the alternative proposition and why is that better?
bq. I would even go so far as to suggest that Y might be incremented at most
once during a release
If by "release" you mean "minor C* release" then I definitely agree (but
honestly never intended otherwise). If it's "major C* release", I disagree.
> 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
