Release Checklist

A green per-package build is not enough. The release is healthy only when every surface agrees on workbook behavior and the compatibility claims still line up with reality.

Glossary: same-revision release

A release where every shipped artifact — WASM, Native Node, Python wheel, CLI binaries, MCP server, formulon-cell — was built from the same Git revision of the core. Avoids the subtle bug where one surface ships a fix and another does not.

Before a release

• [ ] Run core tests (make test-all).
• [ ] Run oracle tests for available profiles (make oracle-verify).
• [ ] Verify WASM size budgets (make size-check).
• [ ] Build JavaScript, Python, CLI, and native artifacts from the same revision.
• [ ] Smoke-test each package surface.
• [ ] Run make parity-test after staging available package surfaces.
• [ ] Run RegistryCatalog.CoverageReport (ctest -R RegistryCatalog.CoverageReport -V from the build directory — diagnostic-only, always passes, reads the coverage percentage from stdout) and update Formula coverage if it changed.
• [ ] Check Compatibility for stale status claims.
• [ ] Update changelog and docs version.

Why each step

Step	Catches
make test-all	Engine-internal regressions
make oracle-verify	Drift between Formulon and captured Excel values
make size-check	WASM bloat that would slow page loads
Same-revision build	Cross-surface drift caused by partial rebuilds
Smoke-test each surface	Packaging or binding-only regressions
make parity-test	Surfaces that compute different values for the same input
RegistryCatalog.CoverageReport	Stale function-count claims in docs
Compatibility audit	"Excel-compatible" claims that no longer hold
Changelog and docs	User-facing surprises after upgrade

Do not treat a green package build as enough

The release is only healthy if the surfaces agree on workbook behavior. A WASM build that recalcs differently from Python is a worse user experience than either build being slightly wrong — at least when they agree, applications can be debugged with one mental model.

After release

• [ ] Tag the release (git tag vX.Y.Z && git push origin vX.Y.Z) — this push is the release: it triggers the tag-driven release.yml workflow, which builds and publishes npm, PyPI, CLI binaries, and the GitHub Release automatically over OIDC trusted publishing. There is no separate manual publish step. Watch the workflow run to completion rather than looking for something to publish by hand.
• [ ] Update the docsVersion in the homepage repo if the docs site tracks it.
• [ ] Watch for incoming compatibility issues and route them to the right oracle / profile.

1. Work on develop
2. Open PR to main
3. CI green
4. Merge
5. Push vX.Y.Z tag

release.yml (tag-triggered)

publish-npm

build-cli

python-wheel

publish-pypi

attach-cli

↓

Result

npm + PyPI + CLI binaries + GitHub Release — live

Read next

• Test matrix — what each test target covers.
• Size budgets — the WASM ceiling.
• Compatibility model — what the claims have to back up.