Yes, if the fix does not change the public API. Semantic Versioning says the patch number must be incremented when only backward compatible bug fixes are introduced. Maven Central's guidance for a published bug also points to a new patch release. A patch tells users the upgrade is safe to take quickly.
What the sources say
The SemVer specification states that the patch version must be incremented if only backward compatible bug fixes are introduced, and defines a bug fix as an internal change that fixes incorrect behaviour. A minor version covers new compatible functionality or deprecations, and a major version covers incompatible changes.
The Maven Central immutability page gives parallel advice. Published components are not removed or modified. If you published a component with a bug, the recommended path, in its words, is a new release with the fix, ideally a patch release if you use Semantic Versioning, to communicate compatibility with the previous version. Then broadcast the release to your users through your communication channels.
Why the label matters
Users and tools decide how fast to act from the version number. A patch bump tends to be accepted quickly, sometimes automatically. If you hide a security fix inside a minor release with new features, many users will delay the upgrade to test the features, and the vulnerable version stays in use longer.
| Fix type | Suggested release | Notes |
|---|---|---|
| Compatible security fix | Patch | State clearly in the notes that it is a security fix |
| Fix that needs a new option or default | Minor | Explain the change and how to opt in |
| Fix that must break the API | Major release | Rare. Document the break in the advisory |
Backport to every supported line
A single patch on the newest line leaves users on older supported lines exposed. Publish a patch for each branch you say you support. The Django project's statement that patch releases are fully compatible, except where security or data loss prevent it, shows the promise users hope to rely on.
What the release notes should say
Note the fixed version, the affected range, the weakness type, and a link to the advisory. The OpenSSF badge criteria also say release notes should identify each publicly known runtime vulnerability fixed in the release that already had a CVE or similar when the release was created, with exceptions for cases where users cannot practically update. Following that makes it easier for scanners and teams to match your fix to their records.
Steps
- Prepare the fix on the main branch with a test.
- Backport it to each supported branch as a patch release.
- Mark each release notes entry as a security fix, with the advisory link.
- Publish the advisory and release on the same day.
- Tell users through the channels named in your security policy.
- Do not edit or replace a published release. Ship a new one.
Try it yourself
Click through it at your own pace, or open it full screen. See how a fixed version is presented, and judge how confident you would be taking an upgrade labelled as a patch.
Quick check
Can I republish the same version with the fix?
Registries such as Maven Central do not remove or modify published components. Publish a new version.
What if the fix needs an API change?
Use a minor or major release as appropriate, and explain the reason and the migration in the advisory.
Should release notes name the CVE?
The OpenSSF criteria say they should for publicly known runtime vulnerabilities that already had one when the release was created.
How Safeguard helps
Safeguard can help you keep the support dates in view. Its SBOM and dependency scanning list the exact versions you run, reachability analysis shows which known issues your code can actually reach, and policies and gates can stop a build that pulls in a version you have decided to retire. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try the free scan on a manifest first.
Sources
- Semantic Versioning 2.0.0, semver.org: patch, minor and major definitions. Fetched 19 October 2026.
- Django Software Foundation, Download Django: patch release compatibility statement. Fetched 19 October 2026.
- Sonatype, Immutability of Published Components: Maven Central guidance on fixing a published bug. Fetched 19 October 2026.
- OpenSSF, Badge criteria, passing level: release notes criterion. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
