Release v19.107.0

Kernel nodes of adjacent releases can now share a cluster during a rolling upgrade, and every release is checked for it before it ships.

Added

• Grain calls are routed by interface version, so during a rolling upgrade a call that needs a newer grain method reaches a node that has it, and older nodes keep being served by newer ones. Upgrading from 19.106 or later can replace nodes one at a time. (#5272)
• Every build and release is checked against the latest release, and fails when a change to a kernel grain interface would stop nodes of the two releases from sharing a cluster. (#4621)
• A rolling upgrade from the latest release to the new build, one node at a time under load, runs in CI. (part of #5169)

Changed

• A node that cannot exchange grain calls with an older node now logs a critical message naming the startup step and saying that every node must be stopped before starting the new version, instead of failing only with Unable to resolve type alias. Upgrading from a 19.x release before 19.106, or to a new major, still needs a full stop. See Roll out a new version to a multi-node Chronicle cluster. (#4325)
• The rolling deploy guide now covers MongoDB clustering as well as Sql, and starts with which versions can run side by side.