[
https://issues.apache.org/jira/browse/CASSANDRA-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-3951:
-----------------------------------
Attachment: 3951.patch.txt
I summarized that position (accurately, I hope) in this patch (tag pending/3951
in my github).
> make thrift interface "backwards compat" guarantee more specific
> ----------------------------------------------------------------
>
> Key: CASSANDRA-3951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3951
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Affects Versions: 0.5
> Reporter: paul cannon
> Assignee: paul cannon
> Priority: Minor
> Labels: thrift_protocol
> Fix For: 1.0.10
>
> Attachments: 3951.patch.txt
>
>
> The comments in cassandra.thrift read:
> {noformat}
> # The API version (NOT the product version), composed as a dot delimited
> # string with major, minor, and patch level components.
> #
> # - Major: Incremented for backward incompatible changes. An example would
> # be changes to the number or disposition of method arguments.
> # - Minor: Incremented for backward compatible changes. An example would
> # be the addition of a new (optional) method.
> # - Patch: Incremented for bug fixes. The patch level should be increased
> # for every edit that doesn't result in a change to major/minor.
> #
> # See the Semantic Versioning Specification (SemVer) http://semver.org.
> {noformat}
> This is great to have documented guarantees, but it is unclear whether the
> "backward compatibility" discussed refers to the Cassandra server being able
> to talk to clients built against older thrift specs, or whether it refers to
> clients being able to talk to Cassandra servers built against older thrift
> specs.
> In a conversation on irc this morning, I found out that it actually meant
> that the former (older clients should be able to talk to a new Cassandra, but
> newer clients are not guaranteed to be able to talk to an old Cassandra). On
> the other hand, people seemed willing to extend the compatibility guarantees
> in *both* directions going forward, since we would like to switch to a
> dedicated CQL transport anyway.
> Either way, the comments in cassandra.thrift should be specific about what is
> guaranteed so that client and library authors, and Cassandra developers, all
> agree what to expect.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
