Check eight things in order: the version number, the artifacts and their signatures, the upgrade and rollback tests, the release notes, the advisory, the supported lines, the download pages and the customer notice. A release that passes all eight can be approved by a customer change board quickly, and that shortens the time they stay exposed.
The checklist
| Step | Check | Why it matters |
|---|---|---|
| 1. Number | Patch bump for a compatible fix, never reuse a number | Customer rules treat patch releases as low risk |
| 2. Artifacts | Built once, signed, hashes published | Customers verify what they download |
| 3. Upgrade test | Previous release to new, on realistic data | Failed upgrades cost more than the flaw |
| 4. Rollback test | New to previous and forward again | Gives customers a safe exit |
| 5. Notes | Security entry with affected and fixed versions | Scanners and humans need the same facts |
| 6. Advisory | Published with the release, not after | Customers need severity and workarounds |
| 7. Supported lines | Fix present on every line still in support | Customers on older lines are not forgotten |
| 8. Notice | Sent to the advisory list and posted on your site | Customers cannot act on what they do not see |
Notes on the hard steps
On numbering, the Semantic Versioning text treats backward compatible bug fixes as patch changes and says a released version must not be modified. See which version number a security fix gets.
On the upgrade test, include the oldest version you claim to support, not only the previous one. A published version skew policy tells you which combinations to test.
On the advisory, include the affected range, the fixed versions on every line, any workaround, and how to check whether a customer is affected. The advisory template lists the fields.
Sequencing on release day
- Freeze the artifacts and compute hashes.
- Sign.
- Publish the artifacts to the download site, in the repository and in the registry.
- Publish the advisory and notes.
- Send the notice.
- Watch support channels for failed upgrades for the first day and keep an engineer on call.
Publishing the advisory before the artifacts exist leaves customers reading about a fix they cannot install. Publishing artifacts before the advisory leaves some customers installing without knowing it matters.
If you must change something after release
Do not replace a file. Issue a new patch version, and withdraw the old one on the download page with a note. See yank or delete a bad release.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate blocks a change until its checks pass.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
Should the advisory go out before the release?
Publish it with the release. Earlier risks pointing attackers at a flaw customers cannot yet fix.
Do I need a rollback test for a small patch?
Yes. A small patch can still include a migration or default change that makes rollback unsafe.
Sources
Last reviewed: 19 October 2026.
