...

• 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

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. 

...