How to patch without breaking your stack
Patch management · 7-min read · Check a version + its upgrade impact → · updated November 2026
Security says “upgrade to the safe version.” Operations says “we can’t — it’ll break something.” That standoff is the single biggest reason security patches sit unapplied. The way out isn’t courage, it’s reading the upgrade risk — because most of the time the version number already tells you how dangerous the jump is.
The version jump tells you the risk
| Upgrade | Breaking-change risk | What to do |
|---|---|---|
| Patch (8.3.1 → 8.3.9) | Low | Apply promptly — backwards-compatible bug/security fixes by design. |
| Minor (8.3.x → 8.4.0) | Moderate | Usually compatible, but can add or shift behaviour. Test in staging, then roll out. |
| Major (8.x → 9.0) | High | Assume breaking changes. Read the vendor migration guide, budget time, and test thoroughly. |
This is semantic versioning in one line: MAJOR.MINOR.PATCH — the MAJOR number only changes when the vendor intends breaking changes. Check your version → and IsItPatched shows both the minimum safe version and the upgrade impact of getting there.
The playbook
Start from the minimum safe version — the lowest release that clears the open critical/high vulnerabilities. That is your target; you don't have to jump to the very latest.
Compare your version to the target. Under semantic versioning, the first number (MAJOR) changing signals intentional breaking changes; the second (MINOR) adds features backwards-compatibly; the third (PATCH) is bug/security fixes only. IsItPatched labels this for you on each version page.
Patch-level → apply now. Minor → test in staging first. Major → treat it as a project: read the migration guide, check deprecations, budget testing time. Don't block a one-line patch upgrade out of major-upgrade fear.
The version jump is a strong hint, not a guarantee. Some products don't follow semver (browsers, date-based CalVer, vendor schemes), and vendors occasionally slip a breaking change into a minor. The vendor's changelog / release notes are the ground truth — read them for the exact version range you're crossing.
Upgrade in staging behind your test suite; canary to a slice of production; keep a rollback path (snapshots, blue-green, pinned previous version). For libraries, update one dependency at a time so a break is easy to attribute.
Don't just accept the risk silently. Apply the advisory's interim mitigations or compensating controls, restrict exposure, and prioritise by exploitation — an actively-exploited (KEV) flaw justifies an emergency major upgrade that a low-EPSS medium does not.
Turn this into action. The #1 reason security patches get delayed is the fear they'll break something. How to read upgrade risk from the version jump (major vs minor vs patch), where the version number lies, and how to de-risk the rollout — so "we can't upgrade" stops being the blocker.
Check a version + its upgrade impact — free →Frequently asked questions
What is a "breaking change"?
A change in a new version that can stop your existing setup from working — a removed or renamed function, a changed default, a dropped API or config format. Upgrading across one is why "just patch it" sometimes isn't just.
What do major, minor and patch mean?
Under semantic versioning (semver), a version is MAJOR.MINOR.PATCH. MAJOR changes may break backwards compatibility; MINOR adds functionality compatibly; PATCH is backwards-compatible bug and security fixes. So a patch-level or minor upgrade is usually low-risk, and a major upgrade is where breaking changes live.
Is a patch-level upgrade always safe to apply?
Almost always — patch releases are meant to be backwards-compatible fixes, so they're the lowest-risk and highest-value upgrades (they often contain the security fix you need). Still test critical systems, as vendors occasionally regress.
Do all products follow semver?
No. Browsers use large sequential numbers (131 isn't a "breaking major" over 130), many products use date-based CalVer (2026.8), and some vendors use their own schemes. For those, the version number doesn't indicate breaking changes — read the release notes. IsItPatched detects this and defers to the vendor's notes rather than guessing.
How do I know the upgrade impact for my software?
On any IsItPatched version page (or after a version check), the minimum-safe-version block shows an upgrade-impact label — major, minor or patch — for the recommended upgrade, colour-coded by risk, with a prompt to check the vendor's guide for anything bigger than a patch.
What if the fix requires a major upgrade we can't do now?
Reduce exposure with the vendor's interim mitigations or compensating controls, and prioritise by real-world risk: an actively-exploited vulnerability (on CISA KEV) warrants the disruption of a major upgrade far more than a low-probability medium. Plan the major upgrade; mitigate in the meantime.
This guide is vendor-neutral and informational, grounded in publicly-available guidance from bodies such as OWASP, NIST and CISA. IsItPatched is independent and not affiliated with them, and this is not legal or compliance advice. See our disclaimer.