Skip to content
mvmforge

Compatibility matrix

mvmforge is the host CLI; mvm-sdk is the language-binding library you import from your decorated app; mvm is the upstream substrate. The three move on independent release cadences but ship in coordinated combinations. Use a row from this table rather than mixing versions ad-hoc.

The source-of-truth is compatibility.toml in the repo root. The CI lane just compatibility-check (wired into just ci) refuses to merge any version bump that doesn’t add a new row, so this page can’t lag the workspace.

Tested combinations

mvmforgemvm-sdk (Python)mvm-sdk (TypeScript)mvmStatusNotes
0.1.00.1.20.1.2b2137b0currentInitial alpha. Function-call entrypoints, deny-default network, deterministic source bundle. Real-VM boot validated against mvm@b2137b0 for both x86_64-linux and aarch64-linux. Pre-W3/W4 transition (factories live in mvmforge; tarball artifacts not yet supported by mvmctl).

Reading the table

  • mvmforge — Rust workspace version (Cargo.toml [workspace.package] version). Same value for the mvmforge host CLI and the mvmforge-ir / mvmforge-runtime crates.
  • mvm-sdk (Python) — sdks/python/pyproject.toml version. Published to PyPI as mvm-sdk (the import path stays import mvm).
  • mvm-sdk (TypeScript) — sdks/typescript/package.json version. Published to npm as mvm-sdk.
  • mvm — short-hash of the mvm flake revision pinned in crates/mvmforge/src/mvm_pin.rs::MVM_REV. Override per-developer with MVMFORGE_MVM_FLAKE_URL for local checkouts.
  • Status — one of current (recommended), supported (older combination still tested in CI), or deprecated (no further validation; upgrade).

Bumping a pinned version

When you bump any of the four pinned values:

  1. Update the manifest (Cargo.toml, pyproject.toml, package.json, or mvm_pin.rs).
  2. Append a new [[combination]] row to compatibility.toml with the new value(s). just compatibility-check will fail until you do — the failure message tells you exactly which row to add.
  3. Update this page’s “Tested combinations” table to reflect the new row (and mark the previous row as supported or deprecated as appropriate).
  4. Re-run just ci and commit all four changes together.

Mixing across rows (“mvmforge 0.1.5 with mvm-sdk 0.1.2 because we haven’t released the new SDK yet”) is unsupported — schema and wire-format invariants only hold within a single combination.

Why not auto-resolve?

A pure dependency-resolution graph (e.g. SemVer ranges in Cargo.toml) covers the same surface for code, but the substrate boundary (mvm ↔ wrappers ↔ wire contract) lives outside Cargo’s view. The table is the explicit cross-repo truth-set; CI checks it programmatically.

See also