mirror of
https://github.com/garrytan/gstack.git
synced 2026-09-27 23:21:53 +02:00
Garry Tan
730a1017d1
* v1.89.1.0 fix: remove continuous checkpoint commits and repair validation blockers * fix: clarify shipping and engineering review recovery * fix: interpret native no-change review descriptions * test: separate descendant readiness from timeout delivery
1.9 KiB
1.9 KiB
Step 13: CHANGELOG (auto-generate)
-
Read
CHANGELOG.mdheader to know the format. -
First, enumerate every commit on the branch:
git log origin/<base>..HEAD --onelineCopy the full list. Count the commits. You will use this as a checklist.
-
Read the full diff to understand what each commit actually changed:
git diff origin/<base> -
Group commits by theme before writing anything. Common themes:
- New features / capabilities
- Performance improvements
- Bug fixes
- Dead code removal / cleanup
- Infrastructure / tooling / tests
- Refactoring
-
Write the CHANGELOG entry covering ALL groups:
- If existing CHANGELOG entries on the branch already cover some commits, replace them with one unified entry for the new version
- Categorize changes into applicable sections:
### Added— new features### Changed— changes to existing functionality### Fixed— bug fixes### Removed— removed features
- Write concise, descriptive bullet points
- Insert after the observed file header, before the first release entry, dated today
- Format:
## [X.Y.Z.W] - YYYY-MM-DD - Voice: Lead with what the user can now do that they couldn't before. Use plain language, not implementation details. Never mention TODOS.md, internal tracking, or contributor-facing details.
-
Cross-check: Compare your CHANGELOG entry against the commit list from step 2. Every commit must map to at least one bullet point. If any commit is unrepresented, add it now. If the branch has N commits spanning K themes, the CHANGELOG must reflect all K themes.
Do NOT ask the user to describe changes. Infer from the diff and commit history.