[ 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