Define versioned wire and storage compatibility for rolling upgrades

[Migorithm]

Problem

Network messages and durable records are serialized directly without a negotiated protocol version or a complete storage-format version policy. Adding, removing, or reordering message alternatives or persisted fields can make mixed-version nodes misdecode traffic or make upgraded binaries unable to read existing state.

A 1.0 compatibility promise needs an explicit supported upgrade boundary and automated enforcement.

Scope

Define compatibility separately for:

• Client-to-broker traffic.
• Consensus traffic.
• Data replication and repair traffic.
• Metadata logs and snapshots.
• Write-ahead logs, segment files, and indexes.

For each boundary, document the version envelope, capability negotiation, unknown-version behavior, and supported upgrade and downgrade paths.

Acceptance criteria

• Every durable and network format with compatibility requirements has an explicit version.
• Peers negotiate or reject incompatible capabilities before exchanging operational messages.
• Unknown versions fail with a clear diagnostic rather than being interpreted as another message.
• The project documents which adjacent releases may coexist and whether downgrades are supported.
• Persisted state created by the oldest supported release can be opened or migrated by the newest supported release.
• Upgrade ordering and rollback behavior are documented.
• Compatibility fixtures prevent accidental format changes from silently landing.
• Release automation detects unreviewed public protocol or storage-format breaks.

Validation

• Run mixed adjacent versions through election, metadata mutation, produce, fetch, segment roll, repair, and restart.
• Open durable fixtures produced by every supported prior format.
• Inject unknown and malformed version envelopes.
• Upgrade and roll back nodes one at a time while traffic continues.
• Verify incompatible combinations fail before mutating durable state.