softprops/action-gh-release
1
0
Fork 0
mirror of https://github.com/softprops/action-gh-release.git synced 2026-03-15 09:20:54 -04:00
Code Issues Packages Projects Releases Wiki Activity

chore: add RELEASE.md

Browse Source 
Signed-off-by: Rui Chen <rui@chenrui.dev>
This commit is contained in:
Rui Chen
2026-03-15 01:56:09 -04:00
parent 1f3f350167
commit 11f917660b
2 changed files with 42 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
AGENTS.md
View File

@@ -67,6 +67,7 @@ For behavior changes, also run the relevant external regression workflow(s) in `
- docs-only changes: `documentation`
- additive features: `feature` or `enhancement`
- dependency updates: `dependencies`
- Follow [RELEASE.md](RELEASE.md) for version bumps, changelog updates, tagging, and release publication.
- Prefer manual issue/PR closeouts with a short rationale over implicit assumptions.
- Do not auto-close old PRs or issues through unrelated docs PRs.

41
RELEASE.md Normal file
View File

@@ -0,0 +1,41 @@
# 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](package.json) to the new version.
2. Add the new entry at the top of [CHANGELOG.md](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](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](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](README.md), [action.yml](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.