[
https://issues.apache.org/jira/browse/CASSANDRA-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554070#comment-13554070
]
Eric Evans commented on CASSANDRA-5156:
---------------------------------------
For what it's worth, the original context was that the versioning was for the
document, which in turn described the language. That's a subtle distinction I
know, but it (essentially) meant that Z (patch-level) was reserved for
non-normative changes, even if it resulted in a normative change to the
document (the document might have been in error, not matching intent or
implementation). I did this because I'd seen it work well elsewhere, but I
don't think we're as pedantic as the group(s) whose example I followed (strange
as it may seem!).
{quote}
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.
{quote}
This is where we're diverging I think, and where I probably haven't done well
expressing myself. I think Y _should_ represent a normative change to the
language. A fixed typo in the document that results in no normative change to
the language isn't very interesting to a user or driver maintainer, but a new
feature that may require driver support to use is (or if it doesn't require
driver support, it at least represents something noteworthy).
I would even go so far as to suggest that Y might be incremented at most once
during a release; A given instance of Y could represent a "release" of an
arbitrary number of new features made during a Cassandra release. Any document
change log could list the individual changes associated with a version. This
would make things even simpler (and would prevent the version inflation you
were concerned about), the only downside I see, is that it might discourage
driver maintainers from tracking changes between releases (though I don't think
that's a given).
So to summarize, I think Z has been demonstrated to be overkill and confusing
and we certainly haven't kept up with it well. I'm not opposed to keeping it,
or getting rid of it. But, I think it would be shame to confound Y and Z in
such a way that it would convey less meaning that it does now.
> 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
