Release Checklist: [Product name] [vX.Y.Z]

Release checklist for a software version: metadata, then task lists for planning, code freeze, QA, security, documentation, packaging and signing, the release itself, post-release checks and rollback readiness, followed by sign-offs and communication. Copy it once per release and tick items as they are done. Replace every [bracketed] value and every line marked Example.

1. Planning

• Scope agreed: list of issues and PRs included, linked from the tracking issue.
• Version number chosen according to [Semantic Versioning]; breaking changes justify a major bump.
• Release dates confirmed with [product, support, operations].
• Owners assigned for QA, security, documentation and communication.
• Dependencies on other teams or services identified, with their release dates.
• Known risks recorded, for example: Example: database migration on a 40 GB table.

2. Code freeze

• Release branch [release/X.Y] created from [main] at commit [sha].
• Branch protection applied; merges need [release manager] approval.
• All included PRs merged; nothing in review is labelled for this release.
• Feature flags for unfinished work are off by default.
• Version number updated in [package.json / pyproject.toml / build files].
• Dependency lockfile committed and unchanged since freeze, unless for a security fix.

3. Quality assurance

• CI green on the release branch: unit, integration and end-to-end suites ([CI run link]).
• Test coverage not below [80%] on changed modules.
• Regression test pass on supported platforms: [browsers / OS versions / devices].
• Upgrade test from the previous [two] versions, including data migration.
• Performance check against baseline: Example: p95 API latency within 10% of v2.3.
• Accessibility check of changed screens ([WCAG 2.2 AA]).
• Exit criteria met: [no open P1 or P2 defects / agreed exceptions listed below].

4. Security

• Dependency audit clean or exceptions approved ([tool, report link]).
• Static analysis (SAST) findings triaged; no new high or critical issues.
• Secrets scan clean on the release branch.
• Container or OS image scan clean for high and critical CVEs.
• Security review completed for changes to authentication, authorization, data handling or cryptography.
• Software bill of materials (SBOM) generated in [CycloneDX / SPDX] format.

5. Documentation

• CHANGELOG updated with Added, Changed, Deprecated, Removed, Fixed and Security entries.
• Release notes drafted for users, in plain language.
• Migration guide written for every breaking change, with before and after examples.
• API reference and configuration docs regenerated.
• Support and operations teams briefed on new behaviour and known issues.

6. Packaging and signing

• Artefacts built by CI from tag [vX.Y.Z], not on a developer machine.
• Builds are reproducible or the build environment is recorded.
• Artefacts signed ([Sigstore cosign / GPG / platform code signing]) and signatures verified.
• Checksums (SHA-256) published alongside artefacts.
• Build provenance attestation generated, for example [SLSA level 2].
• Package metadata correct: version, licence, homepage, minimum runtime.

7. Release

• Go/no-go meeting held; decision recorded in the sign-off table.
• Database migrations applied and verified ([migration log link]).
• Tag [vX.Y.Z] pushed and GitHub release published with notes and checksums.
• Packages published to [npm / PyPI / container registry / app stores].
• Deployment rolled out in stages: [5%] then [25%] then [100%], with health checks between stages.
• Status page or maintenance notice updated, if applicable.

8. Post-release

• Monitoring watched for [24 hours]: error rate, latency, crash rate, key business metrics.
• Smoke tests pass in production ([run link]).
• Support queue reviewed for new issues linked to the release.
• Release branch merged back to [main] where needed.
• Milestone closed and unfinished items moved to the next release.
• Retrospective scheduled for releases that had incidents or waivers.

9. Rollback readiness

Rollback trigger: Example: error rate above 2% for 10 minutes, or any data-integrity defect. Decision owner: [@name].

• Previous version artefacts available and deployable.
• Rollback procedure documented in [runbook link] and tested in staging.
• Migrations are backward compatible, or a down migration is tested.
• Feature flags allow disabling new features without redeploying.
• Estimated rollback time: [minutes].

10. Waivers

11. Sign-offs

12. Communication

Standard and licence note

Based on common industry practice for software release management, including Semantic Versioning, Keep a Changelog style entries and supply chain practices such as SBOMs and signed artefacts. Original text written for this collection. Template licence: MIT.