RELEASE.md

Release Workflow

Use this checklist when cutting a new action-gh-release release.

Inputs

• Decide the semantic version bump first: major, minor, or patch.
• Review recent merged PRs and labels before drafting the changelog entry.
• Make sure master is current and the worktree is clean before starting.

Checklist

1. Update package.json to the new version.
2. Add the new entry at the top of CHANGELOG.md.
   • Summarize the release in 1 short paragraph.
   • Prefer user-facing fixes and features over internal churn.
   • Keep the merged PR list aligned with .github/release.yml categories.
3. Run npm i to refresh package-lock.json.
4. Run the full local verification set:
   • npm run fmtcheck
   • npm run typecheck
   • npm run build
   • npm test
5. Commit the release prep.
   • Use a plain release commit message like release 2.5.4.
6. Create the annotated tag for the release commit.
   • Example: git tag -a v2.5.4 -m "v2.5.4"
7. Push the commit and tag.
   • Example: git push origin master && git push origin v2.5.4
8. Move the floating major tag to the new release tag.
   • For the current major line, either run npm run updatetag or update the script first if the major ever changes.
   • Verify the floating tag points at the same commit as the new full tag.
9. Create the GitHub release from the new tag.
   • Prefer the release body from CHANGELOG.md, then let GitHub append generated notes only if they add value.
   • Verify the release shows the expected tag, title, notes, and attached artifacts.

Notes

• Behavior changes should already have matching updates in README.md, action.yml, tests, and dist/index.js before release prep begins.
• Docs-only releases still need an intentional changelog entry and version bump decision.
• If a release is mainly bug fixes, keep the title and summary patch-oriented; do not bury the actual fixes under dependency noise.