Skip to main content
< All Topics
Print

Release Management

name: release-management

description: Plan, coordinate, and execute software releases including release notes, version management, checklists, and rollback procedures. Use when preparing a product release, writing release notes, planning a deployment, managing a hotfix, or documenting a rollback procedure.

Release Management

Instructions

Manage software releases with rigor, consistency, and documented accountability.

Semantic versioning rules:

  • MAJOR (X.0.0): breaking change — existing configurations or integrations stop working
  • MINOR (x.Y.0): new feature — backward compatible
  • PATCH (x.y.Z): bug fix — backward compatible; also used for hotfixes

Release readiness gate (must pass before any release):

  1. All critical (S1) and high (S2) defects resolved and regression-verified
  2. All medium (S3) defects resolved OR explicitly deferred with stakeholder approval
  3. Release notes written and reviewed for accuracy
  4. Version numbers consistent across all version files
  5. Documentation updated for new/changed features
  6. Rollback procedure documented and tested

Release notes format (Keep a Changelog standard):


## [version] — YYYY-MM-DD
### Added
- [New feature — user-facing description, active voice]

### Changed
- [Behavior change — note if migration/reconfiguration needed]

### Fixed
- [Bug fix — what was broken, what the fix does]

### Removed
- [Removed capability — note migration path]

### Security
- [Security fix — describe risk, not exploit details]

Pre-release checklist template:


□ All gates passed (QA sign-off documented)
□ Release notes drafted and reviewed
□ Version bumped in all relevant files
□ Clean build from main/release branch
□ Build artifact named with version
□ Tested in production-equivalent environment
□ Rollback procedure documented
□ Stakeholder notification drafted

Rollback procedure template:


## Rollback: [Product] v[version]
**Trigger conditions**: [what symptoms require rollback]
**Decision maker**: [who can authorize rollback]
**Steps**:
1. [Step 1 — specific command or action]
2. [Step 2]
**Verification**: [how to confirm rollback succeeded]
**Communication**: [who to notify, what to say]

Hotfix process (for S1/S2 post-release issues):

  1. Confirm severity — is this truly S1/S2? (If not, normal release process)
  2. Create hotfix branch from current production tag
  3. Minimal fix only — no feature additions
  4. Expedited QA: test the specific fix + regression on affected flow
  5. Patch version bump
  6. Post-mortem within 48 hours: root cause, prevention, monitoring improvements

Outputs: Release checklist (pre-release/build/deploy/post-release), release notes in Keep a Changelog format, version bump specification, rollback runbook, post-release monitoring plan.

Table of Contents