Motivation

For now, Ignite cluster can be upgraded only by full cluster restart.

Procedure must be the following:

1. stop all Stop ALL cluster nodes.
2. update Update files on each node.
3. start Start nodes one by one.

So, each Each version update is a means cluster temporary unavailability for the end user.
This is extremely inconvenient, especially for the user, especially one users who use Ignite as a primary data storage.
We must add Other systems supports rolling upgrade feature to the Ignitewhen upgrade made node by node without unavailability period.
After implementing rolling upgrade, Ignite must support the following upgrade procedure:

1. Stop one node.
2. Upgrade files on the node.
3. Start node.
4. Repeat steps 1-3 for each node in cluster.

Description

Rolling Upgrade assume that cluster can consist of Ignite versions nodes of different versions.
So Ignite must provide backward compatibility on network level and ability to work in mixed topology.
Development time checks, tests must be added to provide protection of incorrect patches.
Ignite codebase must be reorganized in a way to clearly distinguish those parts that require compatibility and those who don't.

Let's define clearly, what "backward compatibility" for the network messages means:

...