cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3951) make thrift interface "backwards compat" guarantee more specific
Date Mon, 02 Apr 2012 16:53:24 GMT


Jonathan Ellis commented on CASSANDRA-3951:

To elaborate: the context here is that taking obsolete fields out of the IDL makes it difficult
for some clients (especially java) to support old C* versions even if they want to, since
you'd have to do some crazy classloader stuff to get different jar versions supported.

So as a "we'll try not to make life harder than necessary for clients" position I'm fine with
saying "thou shalt not remove obsolete fields" from the thrift idl.  But more than that we
can't promise from the server side.
> make thrift interface "backwards compat" guarantee more specific
> ----------------------------------------------------------------
>                 Key: CASSANDRA-3951
>                 URL:
>             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
> 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)
> {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:!default.jspa
For more information on JIRA, see:


View raw message