|
| 1 | +--- |
| 2 | +name: changelog |
| 3 | +description: Generate a changelog for a release |
| 4 | +disable-model-invocation: true |
| 5 | +--- |
| 6 | + |
| 7 | +Generate a changelog entry for the CHANGELOG.md file by following these steps: |
| 8 | + |
| 9 | +## 1. Get commits since last tag |
| 10 | + |
| 11 | +Run `git --no-pager log $(git describe --tags --abbrev=0)..HEAD --oneline --no-decorate --first-parent --no-merges`) to get the list of commits. |
| 12 | + |
| 13 | +## 2. Process each commit |
| 14 | + |
| 15 | +For each commit: |
| 16 | +- Extract the PR number from the commit message (e.g., `(#13331)`) |
| 17 | +- Remove the commit SHA and `[6.x]` prefix from the message |
| 18 | +- Fetch the PR author from GitHub using `gh pr view <number> --json author --jq '.author.login'` for all PRs in a single command. |
| 19 | + |
| 20 | +## 3. Skip certain commits |
| 21 | + |
| 22 | +Skip commits that are: |
| 23 | +- Test fixture updates (e.g., "Update composer test fixtures") |
| 24 | +- CI/workflow changes (e.g., "Only run lint workflow...") |
| 25 | + |
| 26 | +Do not skip dependency bumps from dependabot. |
| 27 | + |
| 28 | +## 4. Categorize commits |
| 29 | + |
| 30 | +- **What's new**: Commits that add new features (title contains "Add" or introduces new functionality). An "improvement" is not to be considered new. |
| 31 | +- **What's fixed**: Bug fixes, improvements, translation updates, and other changes |
| 32 | + |
| 33 | +## 5. Format each entry |
| 34 | + |
| 35 | +Format: `- Description [#NUMBER](https://github.com/statamic/cms/issues/NUMBER) by @username` |
| 36 | + |
| 37 | +## 6. Order entries |
| 38 | + |
| 39 | +- Reverse the list so earliest commits come first (git log shows newest first) |
| 40 | +- Within each category, maintain chronological order |
| 41 | +- Translation PRs get moved to the bottom of the list |
| 42 | + |
| 43 | +## 7. Determine version number |
| 44 | + |
| 45 | +- Look at the previous version in CHANGELOG.md |
| 46 | +- If there are new features → increment minor version (e.g., 6.0.0 → 6.1.0) |
| 47 | +- If only fixes → increment patch version (e.g., 6.0.0 → 6.0.1) |
| 48 | + |
| 49 | +## 8. Format the release |
| 50 | + |
| 51 | +```markdown |
| 52 | +## X.Y.Z (YYYY-MM-DD) |
| 53 | + |
| 54 | +### What's new |
| 55 | +- Entry 1 |
| 56 | +- Entry 2 |
| 57 | + |
| 58 | +### What's fixed |
| 59 | +- Entry 1 |
| 60 | +- Entry 2 |
| 61 | +``` |
| 62 | + |
| 63 | +- Use today's date |
| 64 | +- Leave 3 empty lines between releases |
| 65 | +- If there are no new features, omit the "What's new" section |
| 66 | + |
| 67 | +## 9. Update CHANGELOG.md |
| 68 | + |
| 69 | +Insert the new release entry at the top of the file, after the `# Release Notes` heading. |
| 70 | + |
| 71 | +## 10. Provide a summary to the user |
| 72 | + |
| 73 | +Inform the user of anything noteworthy, or any liberties you took. e.g. "I skipped PR 123 because of reason" or "I moved PR 123 to the bottom of the list" |
| 74 | + |
| 75 | +You do not need to list *everything*. Only the noteworthy bits. The user will be able to inspect the diff of the changelog to see what you're adding. |
0 commit comments