Versioning & Stability

MEOS makes explicit stability commitments so that bindings, downstream applications, and persisted data can rely on the library across releases.

The public C API exposed by meos.h follows Semantic Versioning (semver):

Functions that are deprecated in a minor version remain usable through the rest of that major series and are removed only at the next major bump.

Every encoding MEOS defines (WKT, WKB, MF-JSON) carries its own version number, evolved independently of the C API:

• Forward compatibility — readers refuse to load a value whose encoding-version major number is higher than they support, with a clear error.
• Backward compatibility — readers accept any value whose encoding-version is the same major and any lower-or-equal minor.
• Versioning of footer metadata — when MEOS encodings are embedded in a higher-level container format (for example, a Parquet file with custom footer metadata), the container’s footer carries its own version alongside the encoding version, so a reader can detect a version mismatch before attempting to decode any value.

A value written by any MEOS-consuming binding can be read by any other binding linked against a compatible MEOS major version.

The type catalog grows over time as new base types are lifted to their temporal counterparts. Adding a new type is a minor version bump (the C API gains new functions but existing ones are unaffected). Removing a type is a major version bump and is preceded by at least one minor-version cycle of deprecation.

Each binding declares the MEOS major version it supports. Bindings are not required to release in lockstep with MEOS; a typical pattern is that a binding’s x.y release supports MEOS MAJOR for some declared range. See each binding’s documentation for its specific compatibility statement.