A patch version bump is meant to contain only backward compatible fixes, but the promise is a convention, not a guarantee, and it differs by ecosystem. Security releases in particular often arrive as patch versions with unavoidable behavior changes. Treat the number as a hint and test according to what the fix touches.
What the number is supposed to mean
Semantic Versioning says to increment the patch version when you make backward compatible bug fixes, the minor version for backward compatible functionality, and the major version for incompatible API changes. It defines a bug fix as an internal change that fixes incorrect behavior.
That wording explains the trap. If your code relied on incorrect behavior, a correct fix is, for you, a breaking change. And a security fix usually works by making something less permissive.
The Python Packaging User Guide says as much: it notes that security releases often come in patch versions but inevitably contain breaking changes. Plan for that on every ecosystem, whatever the label.
How the ecosystems differ
| Ecosystem | What version numbers signal | What to remember |
|---|---|---|
| npm | Packages commonly follow semantic versioning, and ranges like caret allow minor and patch updates | Ranges let a lockfile move patch and minor versions, so review the lockfile diff |
| Go modules | Version numbers signal API compatibility: a major version signals backward incompatible changes, a minor version backward compatible API changes | A major version above 1 gets a new module path, so a major bump is an explicit import change |
| Python | Packages use either semantic versioning or calendar versioning, and the packaging guide describes both in common use | You cannot assume the third number means patch, so read the project's own policy |
A few details deserve a closer look. The Go documentation describes a major version update to a number higher than v1 as also carrying a new module path with the major version appended, such as a v2 suffix. That makes major jumps visible in code, which is a helpful guard. On the Python side, the guide explains that projects choose semantic or calendar versioning, so a "2026.10" release may mean something very different from a "2.6.1" release.
Test according to risk, not just the label
Use the number to set a minimum, then adjust for what the fix changes.
- Patch bump in a package that parses, authenticates or serializes. Run the full suite and replay representative inputs. These are the places where fixing a bug tightens behavior.
- Patch bump in a utility. The normal test run is usually enough.
- Minor bump carrying a fix. Read the release notes for deprecations and new defaults. Test the features that use the package.
- Major bump carrying a fix. Plan it as a separate piece of work with its own tests and rollback, and consider whether a backported fix exists on your current line.
Check the release notes anyway
The changelog is where a project tells you what the number does not. Look for words such as "now rejects", "no longer accepts", "default changed" and "removed". Our post on reading release notes for security fixes walks through the steps.
Where tooling helps
Dependency scanning and SBOMs help you see which version of each package you actually run in each service, and reachability analysis helps you judge whether the vulnerable code is called. Safeguard provides both, and you can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through to a finding with a fixed version and compare the size of the version jump with the testing you would plan.
Quick check
Can I auto merge every patch bump?
Not safely without checks. Auto merge can suit low risk packages with strong tests and a quick rollback. For parsers, auth and database code, keep a person in the loop.
Does a v0 version follow the same rules?
Semantic Versioning treats major version zero as initial development, where anything may change at any time. Treat every update to a v0 package as potentially breaking.
Sources
- Semantic Versioning 2.0.0
- Python Packaging User Guide, Versioning
- Go documentation, Developing a major version update and version numbers
Last reviewed: 19 October 2026.
