...

• communication: Communication messages consists of two parts:
  
  • Message format: message format itself. Communication API should be reworked to force backward compatible messages.
  • User data: Message can store user data. User data format must be backward compatible.
• discovery:
  • Message format: message format itself. Communication API must be reworked to force backward compatible messages.
• binary marshaller:
  • Currently, binary marshaller code highly coupled with the other Ignite code. We must modularize Binary infrastructure (IEP-119 Binary infrastructure modularization) and provide compatibility guarantees for each part of it.
• features:
  • Framework to enable/disable features for mixed version clusters must be developed.
• affinity: 
  • Affinity function must the same for each online node version.
• management commands
  • arguments
  • results
  • tasks

All subsystem that must be compatible:

1. PDS
   1. partition data
   2. WAL records
2. metadata
   1. binary meta
   2. marshaller
3. communication messages
4. discovery messages
5. binary marshaller format
6. affinity results.
7. management commands
   1. argument 
   2. results
   3. tasks (class names).

Current Ignite codebase

• Is there any primitives, building blocks to provide compatibility?
• Difficulties for day by day coding.
• Compatibility testing.
  • explicit tests.
  • ability to run tests with random node versions
• New feature implementation, enabling.
• patterns for implementing commons cases: new version of algorithmes, testing against new versions.
• Scope of compatibility: 
  • Currently any third-party module can register own ports (messages?) and must be able to track compatibility. 

...