Release & CHANGELOG
Trigger phrases: "release", "cut a release", "changelog", "version bump", "bump the version", "new version", "tag", "semver"
SemVer mapping (derive from Conventional Commits)
fix:→ PATCH (x.y.Z)feat:→ MINOR (x.Y.0)BREAKING CHANGE:/feat!:→ MAJOR (X.0.0)
CHANGELOG (Keep a Changelog)
Headings: Added · Changed · Fixed · Removed · Security · Deprecated.
Every version is dated; the Unreleased section can be auto-populated from commits.
Pre-release gates (all must pass)
- Tests green +
sonarqube-checkPASSED -
dependency-auditclean (0 HIGH/CRITICAL) - CHANGELOG up to date
- Version number conforms to SemVer
- Every distribution channel has a documented way to GET this version. Publishing and reaching users are
different events. A channel whose consumers pin at install time — an editor extension, a plugin, a vendored
copy — leaves them on the version they installed until they ask for a new one, so a security fix ships and
does not arrive. For each channel name the upgrade command in the README, and say plainly where it is not
automatic. This was a real gap: three channels documented
npm i -g/brew upgrade/ a refresh command while the plugin channel documented only how to install.
Tagging
git tag -a vX.Y.Z -m "vX.Y.Z" # asks for approval (§4.4); push on explicit request (§4.5)
DoD
- Correct SemVer bump; complete CHANGELOG; tag + rollback plan ready.