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.

Implementation phases

Phase 0 - Code Cleanup

remove DirectByteBufferStreamImpl V1-V3, keep V4, only.
remove all items from IgniteFeatures and corresponding checks.
remove all code and checks for GridContinuousProcessor#discoProtoVer
TcpDiscoverySpi#setForceServerMode
All old version of classes - keep only max from V2, V3, etc. versions. StartRequestV2 that belongs to internal communication.
Classes releated to thin client, jdbc, odbc interaction must stay.
- StartRequest must be deleted. Rename StartRequestV2 → StartRequest.
- CacheMetricsSnapshot must be deleted. Rename CacheMetricsSnapshotV2 → CacheMetricsSnapshot.
MessageFactory.

Use fieldNumber instead of fieldName provide compatible messages.
Ability to enable compatible Communication in runtime because of fieldNumber overhead.
Distinguish serdes generation from POJO
PR checks for Messages ancestor change with the some warning, labels, etc. that can draw reviewer attention to the possible compatibility issues.

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.
PR checks for Messages ancestor change with the some warning, labels, etc. that can draw reviewer attention to the possible compatibility issues.

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

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.

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

...