Semantic versioning, usually shortened to SemVer, is a convention for numbering software releases so the version number itself communicates the nature of the changes it contains. A SemVer version has three parts in the form MAJOR.MINOR.PATCH, such as 2.4.1. Incrementing the MAJOR number signals a breaking change that is not backward compatible; incrementing MINOR signals new, backward-compatible functionality; and incrementing PATCH signals a backward-compatible bug fix. Optional pre-release and build labels, like 2.4.1-beta.2, extend the scheme for unstable releases. Because package managers rely on these rules to decide which versions of a dependency are safe to install, semantic versioning is not just documentation etiquette, it is the machine-readable contract that drives dependency resolution and, by extension, how security fixes propagate through the ecosystem.
Why semantic versioning matters for supply chain security
Semantic versioning is the language your dependency ranges speak. When a manifest declares a range that accepts "any compatible newer release," it is trusting maintainers to follow SemVer honestly: that a MINOR or PATCH bump will not break or subtly change behavior. That trust cuts both ways for security. On the positive side, it means a patch release fixing a vulnerability can flow automatically to every project whose range accepts it, so a well-numbered fix reaches consumers quickly. On the negative side, it means an automatic upgrade can pull in a compromised or regressed version if a malicious or careless publisher ships harmful code under a PATCH bump that ranges accept without review.
For security triage, SemVer is also how advisories describe exposure. A vulnerability record typically states that affected versions are, for example, everything below a fixed release, and the fix is available in a specific patched version. Reasoning about whether you are affected, and whether the fix is a safe minor bump or a breaking major upgrade, depends entirely on interpreting these version numbers correctly. This is core to supply chain security concepts.
How semantic versioning works
The three numbers are strictly ordered and independently meaningful. Given 1.4.7, a bug fix that changes nothing about the API becomes 1.4.8. Adding a new function without removing or altering existing ones becomes 1.5.0, and MINOR bumps reset PATCH to zero. Removing a function, renaming a parameter, or changing behavior in an incompatible way becomes 2.0.0, resetting both MINOR and PATCH. Versions below 1.0.0 are treated as an initial development phase where anything may change.
Package managers layer range operators on top of these numbers. A caret typically allows updates that do not change the leftmost non-zero digit (so ^1.4.7 accepts 1.5.0 but not 2.0.0), a tilde usually allows patch-level updates (so ~1.4.7 accepts 1.4.9 but not 1.5.0), and explicit comparators let you say things like "at least this version." When a package manager resolves, it picks the highest version each range allows, then records the exact choice in a lockfile. Precedence rules also define ordering for pre-release tags, so 1.0.0-alpha sorts before 1.0.0.
Key points at a glance
| Segment | Increment when | Backward compatible | Example |
|---|---|---|---|
| MAJOR | You make breaking changes | No | 1.9.9 to 2.0.0 |
| MINOR | You add features safely | Yes | 2.4.1 to 2.5.0 |
| PATCH | You fix bugs safely | Yes | 2.4.1 to 2.4.2 |
| Pre-release | Release is unstable | N/A | 2.5.0-rc.1 |
How Safeguard uses semantic versioning
Safeguard reads SemVer the way your package manager does, which lets it reason precisely about both risk and remediation. Our software composition analysis maps advisory ranges against the exact versions in your lockfiles, so a finding reflects whether your resolved version truly falls in the affected range rather than a loose name match. That precision is what separates a real alert from noise.
When a fix exists, Griffin AI uses SemVer to classify the required change: a PATCH or MINOR bump that ranges already allow becomes a low-risk automated pull request, while a MAJOR upgrade with potential breaking changes is flagged for closer review with the compatibility implications spelled out. SBOM Studio records the exact resolved versions so you always have an accurate baseline to compare against when a new advisory lands. The result is remediation guidance that respects the version contract instead of blindly bumping numbers.
Frequently Asked Questions
What do the three numbers in a version like 3.2.5 mean?
The first number, 3, is MAJOR and changes only for breaking, backward-incompatible releases. The second, 2, is MINOR and increments when backward-compatible features are added. The third, 5, is PATCH and increments for backward-compatible bug fixes. Read left to right, the numbers tell you how risky an upgrade is likely to be.
What is the difference between the caret and tilde range operators?
A caret is generally permissive within a MAJOR version, accepting new MINOR and PATCH releases (so ^1.2.3 allows 1.9.0). A tilde is more conservative, typically accepting only PATCH updates within a MINOR version (so ~1.2.3 allows 1.2.9 but not 1.3.0). Tighter operators reduce the chance of an unexpected change slipping in.
Does semantic versioning guarantee an upgrade is safe? No. SemVer is a convention maintainers agree to follow, not something the ecosystem enforces. A publisher can accidentally introduce a breaking change in a MINOR release, or intentionally ship malicious code under a PATCH bump. SemVer tells you what a release claims to be, which is why automated upgrades still need scanning and review.
How does semantic versioning relate to security advisories? Advisories describe affected and fixed versions using version numbers and ranges, so interpreting SemVer correctly is how you determine whether your resolved version is vulnerable and how large the fix is. A patched release in the same MAJOR line is usually a safe upgrade, while a fix that only exists in a new MAJOR version may require code changes on your side.
Ready to see whether your resolved versions fall inside real advisory ranges? Create a free account at app.safeguard.sh/register and start scanning, then keep learning with the free Safeguard Academy.