...

•  modularize BinaryMarshaller.
•  create small jar for ignite thin client (get rid of Unsafe). As a separate module, not part of the core. Optional, helps to see if changes affect resialization.
•  provide clear API for binary objects inside ignite-code and other modules. (toCacheObject()). Finish IEP-119. Optional, helps to see if changes affect resialization.

...

•  Communication MessageWriter and MessageReader are aware of peers version, and then schema of a message.
•  Distinguish serdes generation from POJO
•  Guarantee that all messages use new serialization framework. Remove previous framework classes.
•  Code checks, see Communication protocol#Codechecks

Discovery SPI Compatibility

•   Serdes changes to provide compatibility? (current approach with JDK serialization provides some compatibility (13).
  Is it enough for long-term compatibility support?
•   Serdes changes to restrict classes that can be sent over SPI.
•  Guarantee that all messages use new serialization framework. Remove previous framework classes.
•  Code checks, see Communication protocol#Codechecks

Cluster content management

...

Public API PR validation

• PR checks for Messages  ancestor change with the some warning, labels, etc. that can draw reviewer attention to the possible compatibility issues.

...

• Provide ability to change arg, result classes in compatible way.
  • Possible approach is to reuse communication serdes framework.
  • Other possibility is to migrate on BinaryObject as a arguments and results.
• PR checks for Messages  ancestor change with the some warning, labels, etc. that can draw reviewer attention to the possible compatibility issues.

IgniteFeatures 

• Write down clear rules to deal with the new features and not compatible enhancements.
• Support, if not, already this rules in IgniteFeatures framework.

Compatibility Matrix

• A way to declare one version as incompatible with another.
• A component to enforce a rule that only compatible versions can join one cluster. 
• Only nodes with close versions (like 2.17 and 2.18, not 2.17 and 2.19) should be allowed to join cluster.

Testing

• ducktests to check upgrade procedure.
• unit tests mode that start some nodes of previous version. 

...

• Any change in public API MUST be in the form of IEP.
• Any change in public API MUST be voted by two(three?) committers.
• Documentation with clear description of development rules for all subsystems required to be compatible.
• Each release should be started with compatibility code removal.

Alternative designs

• subsystem API versions (like in REST API)
• runtime component(IgniteProcessor, IgniteManager) upgrade with the dynamic class loading. 

...