[FEATURE] Define forwards-compatibility policy

[Kern--]

Description

The SOCI snapshotter and SOCI CLI have different deployment mechanisms and therefore have different update lifecycles. It's likely that this will lead to indices being created using a different SOCI version than the snapshotter that uses the indices.

Older CLIs used with newer snapshotters falls under the backwards compatibility requirements of semantic versioning. However, newer CLIs used with older snapshotters could add features that the snapshotter can't consume. Breaking changes to the zTOC format will bump the zTOC version, but things like adding a compression algorithm don't change the zTOC format, but won't work with older snapshotters. We should define what sort of guarantees we have around these sorts of changes: e.g. do we expect lazy loading to work, but for the new features to be ignored? Are there no guarantees? Do we always add features to the snapshotter first so we can guarantee 1 minor version of forwards compatibility?

Describe the solution you'd like

I would like a doc that explains what sort of forwards-compatibility guarantees we are making, if any.

Describe any alternative solutions/features you've considered

No response

Any additional context or information about the feature request

#579 added support for uncompressed layers. If someone uses a newer CLI to create an index with an uncompressed zinfo and then uses the older snapshotter that can only handle gzip, what should happen?

[sparr]

Please address the possibility that versions come out unscheduled and close together, which makes deprecating functionality more problematic on short notice.