Cutting a release

A release is a tag on the branch that owns the line: <branch> below is main for the current major and release/3.x for 3.x maintenance. Every step runs against that branch, including the docs PR, so a maintenance entry lands in the maintenance branch's own changelog above its newest 3.x entry. The tag triggers Publish fastmcp-slim to PyPI; its success fans out to fastmcp-tasks, fastmcp-remote, and fastmcp, and the fastmcp publish job opens the published-docs PR that makes gofastmcp.com reflect the release. Two hand-maintained docs files mirror every release and must be on the tagged commit, so the docs PR always lands first. PyPI releases are immutable; a bad one gets a follow-up patch, never a re-tag.

Procedure

1. Preview what's in it.

   git fetch origin && git log v<prev>..origin/<branch> --format='%h %s'
   gh api -X POST repos/PrefectHQ/fastmcp/releases/generate-notes \
     -f tag_name=v<new> -f target_commitish=<branch> -f previous_tag_name=v<prev> --jq .body \
     > /tmp/generated-notes.md
   uv run scripts/release_contributor_credit.py /tmp/generated-notes.md \
     > /tmp/contributor-credit.json
   

   Read the two most recent releases for voice: gh release list -L 5, then gh release view <tag> on each.

   Review the scan's attribution candidates. The helper batch-fetches metadata only for PRs in the generated notes. It suggests shared credit for human authors of the PR commits and final merged commit, plus issue reporters whose issues are closed by a maintainer PR, even when their co-author trailer is missing. Human co-authors are included even when the PR has no linked issue. It excludes known agent identities and bots; a GitHub User identity alone does not prove someone is human. Maintainer permission checks are reused across PRs.