When asked to update or review the changelog, focus on user-visible changes and keep entries concise.
- Compare against the previous release tag, for example
v2.3.9..masterwhen preparing2.4.0. - If the changelog branch contains changelog-only commits on top of
master, compare againstmasterto avoid including those commits in the review. - Check whether the previous release tag is on the same ancestry path. If not, identify the practical post-release bump commit and compare from there as needed.
- Include features, fixes, improvements, regressions, deprecations, removals, and security-relevant behavior changes that users, admins, plugin authors, API users, or integrators may care about.
- Include UI fixes when they affect real usage, even if the code change is small.
- Include permission, authentication, wallet, checkout, Point of Sale, subscription, rate provider, plugin compatibility, and API behavior changes when they affect users or integrators.
- Include removals and deprecations under
Miscellaneousunless they fit better under another existing section.
- Skip purely internal refactors, file moves, test-only changes, warning fixes, dependency bumps for tests, and CI/tooling changes unless they affect users or release operators.
- Skip very technical route/controller/view-model reshuffling unless it changes public behavior or public API usage.
- Skip duplicate commits already covered by a previous patch release section.
- Use short bullet points under sections such as
New features,Fixes,Improvements, andMiscellaneous. - Prefer imperative phrasing:
Add,Fix,Allow,Improve,Remove,Deprecate. - Keep capitalization consistent with existing entries.
- Use product terminology consistently, for example
Point of Sale,Pull Payments,Pull Requests,Invoices,Apps,Keypad Point of Sale, andGreenfield API. - Wrap code identifiers and permissions in backticks, for example
`CanSendStoreEmail`. - Include PR or issue numbers when available, for example
(#7379)or(#7383 #7386). - Include the contributor handle at the end when known, for example
@NicolasDorier.
- Review the final diff with
git diff -- Changelog.md. - Run
git diff --check -- Changelog.mdto catch whitespace issues. - Verify authorship for added entries with
git show --no-patch --format='%h %an <%ae> %s' <commit>when attribution is not obvious.