MC has a version, properly this time

A version number that means something

The footer carries MC v0.3.0 from this release on. On production, that’s the bare canonical version. On the next staging branch and in local dev, it carries a -next.N suffix where N is the count of commits ahead of main, so progress is visible during development. There’s also a small corner pill on non-production environments showing the same thing as a fast-glance signal.

The number itself is a reset. The April 1 release was labeled 1.1 retroactively, but the product isn’t at 1.0 yet — that label is reserved for the moment the Craftsman skill and the wiki launch publicly with paid access. Until then, we stay in the 0.x.y band, which by convention signals “interface may change.” That matches what’s actually true about the product.

A release ritual designed for how we actually ship

The internal mechanics are a hand-rolled version of the Changesets pattern (used by pnpm, Astro, Remix, the Vercel AI SDK). Most pull requests are not release-worthy on their own — bug fixes inside existing surfaces, refactors, validator updates — and don’t carry any version-bump intent. The release-worthy ones add a small file at .changeset/<slug>.md declaring patch | minor | major plus a one-line summary. Multiple PRs accumulate multiple files with no merge conflicts.

When it’s time to cut a release, npm run release reads everything in .changeset/, picks the highest bump (major beats minor beats patch), updates VERSION, drafts the release note you’re reading right now, and deletes the consumed changeset files. The script never commits — that part is still manual, so the prose can be polished before it ships.

What stops releases from drifting silently

Three things, all running in CI:

A coherence check verifies that any PR touching VERSION also adds a release note and empties consumed changesets — all three together, or none. Hand-edits to VERSION are rejected.

A worthiness heuristic posts a dismissible comment when a PR touches reader-facing surface (new pages, new content packs, substantial component changes) without including a changeset. It’s a warning, not a blocker — the call is still the author’s.

A monthly canary opens an issue when main accumulates commits without a release. The threshold is currently 20 commits; we’ll tune it after a few months of real cadence.

What this enables

This release exists because the next several months of work will ship in a pattern that benefits from version coordination. The Craftsman skill is heading toward public launch. The wiki has topic pages that need their own per-page versioning to coexist with the site version. Release notes need to actually describe what shipped, not get retrofitted from commit logs after the fact.

The 0.3.0 jump from 0.2 reflects the size of the change: a new end-to-end editorial pipeline for releases. From here, expect patch bumps for fixes and polish, minor bumps for new surfaces, and a major bump only when the product itself paradigm-shifts.

See docs/6-REFERENCE/semver-rules.md for the bump-classification rules. The full architecture lives at docs/2B-PROJECTS/site-wide-semver/v1/RESEARCH.md for anyone curious about the design.