Skip to content

Release Process

Releases use Conventional Commits and release-please as the canonical release PR and changelog mechanism. Release Drafter is not used.

The release-please workflow uses the repository-scoped GITHUB_TOKEN with the least-privilege permissions declared in .github/workflows/release-please.yml. No long-lived release token is required.

Normal Release

  1. Confirm CI, Security, CodeQL, docs, and release checks are green.
  2. Merge the release-please PR.
  3. Confirm .github/workflows/release-please.yml created the release tag and GitHub Release from release-please outputs.
  4. Approve the protected release environment gate for the publish job.
  5. Confirm PyPI publish, SBOM, checksums, Sigstore signing artifacts, and GitHub attestations.
  6. Confirm docs deploy to the canonical repository gh-pages branch and https://oaslananka.github.io/kicad-mcp/ Pages site.
  7. Post a short GitHub Discussions announcement.

Release Workflow

The release workflow has no operator-supplied version fields. Release-please derives the version from Conventional Commits and .release-please-manifest.json. When release-please reports that a release was created, the publish job checks out the release tag, runs the full verification gate, builds artifacts, generates SBOM and checksum files, creates provenance attestations, signs artifacts, publishes to PyPI through trusted publishing, verifies the package with a clean uv environment, and attaches release assets to the GitHub Release.

Publishing must not be triggered from pull requests, forks, local shells, or manual tag creation.

Hotfix

Use hotfix/<issue> for urgent security, data loss, or production blocking fixes. Cherry-pick to a maintained release branch only when that branch exists and has users.

Version Metadata

Run this before release PR review if metadata changes are manual:

pnpm run metadata:sync
pnpm run metadata:check

pyproject.toml is the source of truth for server.json.