Versioning and release notes

This page is the version-control notice for the LMP documentation and runtime. The current repository package line is 0.1.0. It is a pre-release development state, not a claim that a stable public release has been published. The checkout currently has no Git release tag, so treat the commit you are using as the exact source of truth.

The first public product release is v0.1.0. A v1.0.0 tag is reserved for a later production milestone after the end-to-end release evidence is complete.

Current release state

The version badge at the top of this page is intentionally explicit. When a release is published, it must be changed together with the package manifests, release tag, and release notes. Do not infer “stable” from a passing local build.

What is being versioned?

LMP has several versioned layers with different compatibility boundaries:

• Runtime and workspace packages: the Rust workspace and the published JavaScript-facing packages currently use the 0.1.0 development line.
• Mind Packages: each profile has its own version and must be identified by its Mind ID, version, digest, and signature. A Mind Package version is not the LMP runtime version and does not determine the product release tag.
• Artifacts and results: evaluation artifacts record the evaluator version, profile identity, profile digest, source revision, and selected scope so a decision can be reproduced later.
• Documentation: the docs describe the behavior of the checked-out source; they do not replace a release tag or immutable package artifact.

Versioning policy

LMP follows semantic versioning for public runtime and package interfaces:

• Patch releases fix defects without intentionally changing supported behavior or public contracts.
• Minor releases add backward-compatible commands, fields, rules, or integrations. New optional result fields are allowed in this category.
• Major releases change a public command, schema, evaluator decision, signature contract, or other behavior that existing consumers must adapt to.

Changes to Mind schema semantics, evaluator behavior, artifact formats, cryptographic verification, sandbox permissions, remote synchronization, or agent integration contracts require release review. A release must identify which claims were tested, which were simulated, and which remain unproven.

Release notes

v0.1.0: pre-release development line

This line contains the initial integrated protocol foundation:

• Rust workspace and evaluator/daemon surfaces;
• signed Mind Package loading and verification;
• the unified onboarding wrapper and generated workspace contract;
• changed-file evaluation and machine-readable evidence artifacts;
• local MCP adapter and documentation portal foundations.

This release line still requires qualification evidence and an independent human adoption pilot before it should be described as stable or generally production-ready. See the release readiness section on this page for the required evidence boundary.

How to identify an exact version

For a reproducible run, record all of the following with the result artifact:

1. the LMP Git commit or release tag;
2. the runtime/package version;
3. the Mind ID and Mind Package version;
4. the profile digest and signature status;
5. the operating system, Rust, Node.js, and Python versions when applicable;
6. the evaluator command, selected scope, and generated result.

When installing a published release, use the release tag and matching package versions. When working from source, pin the commit and do not report the run as a published release merely because the workspace builds successfully.

Release readiness

Do not publish on the basis of a passing unit-test suite alone. A release candidate needs a clean Rust build and test run, schema and signature rejection fixtures, CLI and MCP smoke tests, isolated brownfield benchmark results, evidence that guidance changes the agent-facing input, evidence that enforcement changes the final decision, documented limitations, and commands that another person can rerun.

The machine-readable gates must be complete, not merely present:

• qualification-result.json reports status: "complete" with 38 of 38 checks and Docker required;
• real-world-benchmark.json reports status: "complete" with 64 of 64 scenarios, 128 paired Docker gates, 128 compiler-control checks, verified provenance, and independent reviewer annotations;
• onboarding-current.json contains measured greenfield and brownfield runs of packages/create-lmp/bin.ts, each below the 3,000 ms target without source code or secrets in the artifact.

blocked, failed, incomplete, missing, or stale artifacts stop the release decision. A benchmark that did not build or execute the required Docker image is not an end-to-end result.

The deployment gate must compare the hosted registry.json with the checked-in index and verify each manifest's digest and identity. The release archive gate must verify every target archive against SHA256SUMS, reject unsafe paths, and require the expected binaries. A reachable page alone is not deployment proof.

The release workflow applies the same aggregate decision immediately before publishing archives. It requires independent annotations for the measured commit and a validated, redacted human adoption report. Neither is inferred from the benchmark itself.

One report for the whole decision

Compose the gates into one fail-closed report. The command exits with status 2 until every required local and external evidence item is present:

python3 orchestrator/release_readiness.py \
  --qualification lmp-test-results/qualification-result.json \
  --benchmark lmp-test-results/real-world-clean-current/real-world-benchmark.json \
  --registry registry/registry.json \
  --deployment https://your-deployed-host.example \
  --expected-registry registry/registry.json \
  --check-manifests \
  --verify-cids \
  --release-artifacts ./release-artifacts \
  --resource-report lmp-test-results/resource-gate.json \
  --onboarding lmp-test-results/onboarding-current.json \
  --human-pilot-report lmp-test-results/human-adoption-pilot.json \
  --require-clean \
  --output lmp-test-results/release-readiness.json

Each blocked check identifies whether its boundary is local, external, or human. The release note must state what was proven, what was simulated, and what still requires an independent adoption pilot.

Prepare a signed release

Use orchestrator/git_release.sh to prepare a release. The default command is read-only and prints the manifests it would synchronize. Applying changes, creating a signed tag, and pushing to the remote are separate explicit steps.

Review the release plan

./orchestrator/git_release.sh v0.1.0

This validates the version shape and existing Git references without changing files, commits, tags, or remotes.

Prepare and sign

./orchestrator/git_release.sh v0.1.0 --apply --tag

Before changing versions, the script requires a clean working tree. It then runs formatting, tests, release builds, integration checks, the Docker-backed qualification matrix, registry and deployment gates, version synchronization, the 64-scenario real-OSS benchmark, and the final signed Lore-format commit. The tag is created only after the required evidence passes for the exact revision that will be tagged.

The tag operation requires a configured Git signing key. If signing is not available, the command fails rather than silently creating an unsigned tag.

After the tag is pushed, the GitHub release workflow builds Linux, macOS, and Windows archives and verifies their contents and SHA256SUMS. A local tag is not release evidence until the hosted matrix completes.

Push after review

./orchestrator/git_release.sh v0.1.0 --apply --tag --push

--push requires --tag and pushes the current HEAD plus the signed tag to origin. Review the generated commit and evidence artifacts before using it. The release script has no benchmark bypass. Missing Docker, qualification, or benchmark evidence is a blocked or failed release, not a successful one.

The script synchronizes Rust crate manifests and Node package manifests. It does not rewrite protected design documents, generated lockfiles by hand, or unrelated working-tree changes.