Plannotator Release

The process has four phases. Phase 1 (release notes) is where most of the work happens, present the draft for review before proceeding to later phases.

Phase 1: Draft Release Notes

This is the most important phase. The release notes are the public face of each version and the primary way the community sees their contributions recognized.

Step 1: Determine scope

1. Find the latest release tag: git tag --sort=-v:refname | head -1
2. Determine the new version number. Ask the user if unclear (patch, minor, or major).
3. Gather all changes since the last tag:
   • git log --oneline <last-tag>..HEAD for commit history
   • git log --merges --oneline <last-tag>..HEAD for merged PRs
4. For each PR, use gh pr view <number> --json title,author,body,closedIssues,labels to get details.

Step 2: Research contributors

This is critical. Every person who participated in the release gets credit, not just PR authors.

For each PR and linked issue, collect:

• PR authors, the person who wrote the code
• Issue reporters, who filed the bug or feature request
• Issue commenters, who participated in the discussion with useful context
• Discussion creators, who started relevant GitHub Discussions
• Feature requestors, check the linked "closes #N" issues and their authors

Use the GitHub API via gh:

# Get issue details including author
gh issue view <number> --json author,title,body

# Get issue comments to find participants
gh api repos/backnotprop/plannotator/issues/<number>/comments --jq '.[].user.login'

# Get PR review comments
gh api repos/backnotprop/plannotator/pulls/<number>/comments --jq '.[].user.login'

Step 3: Write the release notes

Read the reference release notes in references/ for the canonical template structure. These are real release notes from previous versions, match their tone, structure, and level of detail.