An upgrade ticket is done when the new version is merged, deployed to production, verified there, and recorded, with the old version gone from every place it ran. Closing at "pull request merged" is the common mistake, because a merged change that never shipped fixes nothing.
Why the definition matters
Upgrade tickets are unusually easy to close early. The diff is small, the tests pass, the reviewer approves. Then the image is not rebuilt, the service is not restarted, or a second lockfile still pins the old version. Months later a scan shows the vulnerable version in production, and the ticket says Done.
A written definition of done makes the end state explicit. It also makes quarterly reporting honest.
The seven-point checklist
- Merged. The change is on the main branch with a reviewed pull request.
- Built. A new artifact or image exists that contains the new version. For container images, confirm the base image tag or digest changed.
- Deployed. The new build is running in production, not just staging.
- Verified. Someone confirmed the running version, using a version endpoint, a software inventory or a rescan, and a smoke test passed. Our guide to what counts as patched walks through this.
- Old version gone. No other manifest, lockfile, vendored copy, or image layer still carries the previous version.
- Recorded. The ticket links the pull request, the deploy and the verification. If the upgrade closes a vulnerability, the advisory record is updated.
- Communicated. If behaviour changed for users or other teams, there is a release note or a message in the right channel.
Adjust by type
Not every item applies to every ticket. A table keeps it practical.
| Upgrade type | Add or stress |
|---|---|
| Patch bump of a leaf library | Items 1 to 4 are usually enough |
| Major framework upgrade | Add rollback plan and a staged rollout |
| Base image or runtime | Rebuild every dependent image, verify each |
| Security fix | Item 4 with evidence, and update exception records |
| Shared internal library | Track consumer adoption, not just the release |
Put it in the ticket template
A checklist nobody sees is not a definition. Add the seven points to the issue template for upgrade tickets, with checkboxes. Reviewers can then ask which boxes are unticked, instead of debating whether the work feels finished.
Common ways tickets close too early
- The pull request merged but the deploy waited behind a freeze.
- Staging updated, production did not.
- A monorepo package was bumped, but a sibling package kept its own copy of the old version.
- The scanner still flags the package because of a cached layer. See why a scanner can flag a package you already upgraded.
What to measure
Count tickets closed per quarter, and also tickets reopened because verification failed. A rising reopen rate means the definition is not being applied. A cycle time measured to production, not to merge, tells you how long exposure really lasted.
Where Safeguard fits
Safeguard's dependency scanning can rescan after a deploy to confirm the old version is gone, and its evidence automation keeps the record for audits. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a merged pull request ever enough?
Only for changes that deploy automatically and are verified by a pipeline step. Otherwise, wait for deploy and verification before closing.
Who verifies?
Preferably someone other than the author, or an automated rescan. The point is a second check on the running system.
Last reviewed: 19 October 2026.
