The compiler follows semver: MAJOR.MINOR.PATCH.
- MAJOR — breaking changes to language semantics, C codegen ABI, or CLI interface
- MINOR — new language features, new builtins, new CLI flags, new bundled library
- PATCH — bug fixes, codegen correctness, test coverage improvements
Source of truth: Cargo.toml version field, read at build time via env!("CARGO_PKG_VERSION") and surfaced through src/identity.rs.
Each library has its own independent semver version in its m2.toml manifest (version= field).
- 0.x libraries — any minor bump may include breaking API changes (per semver spec)
- 1.0.0+ libraries — standard semver guarantees apply; breaking changes require a major bump
A library graduates to 1.0.0 when all three conditions are met:
- Stable public API — no
.defchanges in 2+ compiler releases - Downstream consumer — used by at least one other library, tool, or example app
- No planned rework — no known API design issues flagged for redesign
- mxpkg — version in
tools/mxpkg/m2.toml - mxpkg0 — version in
tools/mxpkg0/Cargo.toml - VS Code extension — version in
tools/vscode-m2plus/package.json
All tools follow semver independently. CLI flags and subcommands are part of the API surface.
Libraries ship with the compiler but are not version-locked to it.
- A compiler release bundles specific library versions, recorded in a release manifest
- Upgrading the compiler may upgrade bundled libraries; the manifest documents exactly which versions
- Libraries can be updated independently via mxpkg when the registry is available
Internal format versions (manifest_version, plan_version, etc.) are integer counters, not semver. Increment only on breaking format changes.
Each compiler release has a corresponding releases/mx-X.Y.Z.toml file recording all bundled component versions. This is the machine-readable record of what shipped together.
- Update
Cargo.tomlversion - Update
README.md"What's new" section - Create
releases/mx-X.Y.Z.tomlwith all bundled versions - Tag the git commit with
vX.Y.Z