[ 
https://issues.apache.org/jira/browse/CASSANDRA-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985798#action_12985798
 ] 

Gary Dusbabek commented on CASSANDRA-1923:
------------------------------------------

bq. 3. It doesn't need to be an inner class unless you're creating MS 
references.
It would need to be inner to be available outside the package (like in the 
SerializationTests that convert commands into messages and then serializes the 
messages).

bq. it shouldn't be necessary if new node always uses the version it's inferred 
to create messages.
The new node cannot infer a version if it has never communicated with the old 
node.

> unit tests that validate that message serialization isn't broken in the 
> current version.
> ----------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-1923
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1923
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Gary Dusbabek
>            Assignee: Gary Dusbabek
>            Priority: Minor
>             Fix For: 0.7.1
>
>         Attachments: 
> v2-0001-ICompactSerializerTest-assures-serialization-assumptio.txt, 
> v2-0002-remove-unused-constructor-in-EstimatedHistogram.txt, 
> v2-0003-Serialization-tests.txt, 
> v2-0004-build-changes-to-run-serialization-tests.txt, 
> v2-0005-0.7-message-serialization-test-binaries.txt, 
> v2-0006-bounce-messages-from-newer-versions.txt
>
>
> There are two components to this.  First, code that will generate the 
> serialized messages.  Second, code that will attempt to read the serialized 
> messages.
> My plan is to commit this to 0.7.1 with generated serialized messages.  Then 
> I will merge that into trunk sans the generation code.  A similar process 
> will need to take place when we branch trunk to create 0.8, etc.  On second 
> thought, maybe it makes sense to keep the generation code and let it morph as 
> the message formats change.
> If the tests ever break in the 0.7 branch, that means we've created a message 
> incompatibility regression that needs to be fixed.  If the tests ever break 
> in trunk (post CASSANDRA-1015), it means that something in trunk has changed 
> message serialization compatibility that will need to be restored (via 
> whatever process is used for 1015).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to