Release process

This page is the development-facing release checklist. User-facing release notes remain in CHANGELOG.md and docs/release.md.

Release model

• Versioning follows Semantic Versioning for the Python server and matching wrappers.
• Release PRs are generated by release-please.
• Publishing runs from GitHub Actions, not from a maintainer workstation.
• Artifact-specific workflows attach checksums, SBOMs, provenance, and attestations where supported.

Pre-release checks

Before approving a release PR:

corepack pnpm run check:meta
corepack pnpm run check:lint
corepack pnpm run check:type
corepack pnpm run check:test
corepack pnpm run check:security
corepack pnpm run check:workflows
corepack pnpm run check:build

If the full suite exceeds local time limits, run the same underlying pytest suites in documented chunks and record the evidence in the PR.

Release validation

.github/workflows/release.yml is a low-risk validation workflow. It checks release metadata and package build behavior without publishing artifacts or requiring secrets.

Post-release checks

After a release is published:

1. Verify GitHub Release notes are human-readable.
2. Verify package versions match pyproject.toml, package.json, server.json, and registry metadata.
3. Verify checksums and release evidence artifacts are attached where expected.
4. Verify package installation smoke tests.
5. Update OpenSSF evidence if release process or artifact classes changed.

Do not do

• Do not publish from a local workstation.
• Do not bypass protected environments for production package registries.
• Do not manually edit generated metadata without running metadata sync checks.
• Do not claim SLSA level without explicit per-artifact evidence.