No, build metadata is a poor way to label a hotfix. The Semantic Versioning specification says build metadata must be ignored when determining version precedence, so 1.4.0+hotfix1 and 1.4.0 compare as equal. Package managers and scanners will not treat the hotfix as newer. Bump the patch number.
What the spec says
Semantic Versioning lets you append a plus sign and dot separated identifiers to a version. The specification states that build metadata MUST be ignored when determining version precedence, and that two versions differing only in build metadata have the same precedence. It also says the patch number must be incremented when only backward compatible bug fixes are introduced, and defines a bug fix as an internal change that fixes incorrect behavior.
A security fix that does not change the public interface fits that definition exactly.
Why this matters for security
Version comparison is how everything downstream decides whether a fix is present:
- A dependency range such as at least 1.4.1 will not match 1.4.0+hotfix1.
- A vulnerability database that says fixed in 1.4.1 gives no signal about your private label.
- Update bots look for a higher version, not a different suffix.
If you label the fix with metadata only, your customers keep seeing the vulnerable version as current, and any scanner that reads the version string will keep flagging it.
What build metadata is good for
| Use | Example | Fine? |
|---|---|---|
| Record a commit hash | 1.4.1+sha.5114f85 | Yes |
| Record a build date or number | 1.4.1+build.220 | Yes |
| Mark a security fix | 1.4.0+hotfix1 | No, use 1.4.1 |
| Mark a patched fork | 1.4.0+acme1 | Avoid; tools cannot tell it is newer |
Steps
- Increment the patch number for every released fix, however small.
- If you want a trace to the build, add metadata after the new version, such as the commit hash.
- State the fix in the changelog under that exact version.
- Make sure the tag name equals the version in the manifest.
- If you must patch a fork of someone else's package, say clearly in your own records which upstream version the fork tracks, because the string alone will not tell scanners.
If your ecosystem has its own rules
Not every ecosystem follows semver. Some use their own scheme for pre-release and post-release suffixes, and the sorting rules differ. Check how your package manager compares versions before inventing a label. The rule of thumb still holds: if tools cannot sort it as newer, they cannot know it is fixed.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each component is listed with an exact version, the string that all matching depends on.
Safeguard builds an SBOM and dependency inventory from exact versions, so a clean patch bump is what moves a component from flagged to clear. A free scan is available at gold.safeguard.sh/scan.
Quick check
Does 1.4.0+hotfix1 count as newer than 1.4.0?
Not under the semver specification. Build metadata is ignored for precedence, so they are equal.
Is a security fix a patch or a minor release?
If it only fixes incorrect behavior without a backward incompatible change, the spec calls for a patch bump.
Sources
Last reviewed: 19 October 2026.
