1
0
0
0
1
0
0
0
Semantic Versioning (SemVer) is the dominant version numbering standard in modern software development, used by millions of packages across npm, PyPI, Maven, NuGet, and virtually every major package registry. The Semantic Versioning Calculator takes your current version number and a bump type, then computes the correct next version according to the official SemVer 2.0.0 specification created by Tom Preston-Werner, co-founder of GitHub.
The SemVer format follows a strict MAJOR.MINOR.PATCH structure where each number conveys specific meaning about the nature of changes. A MAJOR bump signals backward-incompatible API changes that may break dependent code. A MINOR bump indicates new functionality added in a backward-compatible manner. A PATCH bump represents backward-compatible bug fixes. This systematic approach eliminates the ambiguity of ad-hoc versioning schemes and gives consumers clear expectations about upgrade safety.
Understanding version bumping rules is essential for package maintainers, library authors, and DevOps engineers who manage dependency trees. When you bump the major version, both minor and patch reset to zero (e.g., 1.4.2 becomes 2.0.0). When you bump minor, only patch resets (e.g., 1.4.2 becomes 1.5.0). Patch bumps simply increment the last number (e.g., 1.4.2 becomes 1.4.3). These reset rules are critical because they signal the scope of changes to downstream consumers.
The implications of correct versioning extend far beyond aesthetics. Package managers like npm use SemVer ranges (^1.4.0, ~1.4.0) to automatically resolve compatible updates. A miscategorized breaking change published as a minor or patch version can cascade failures across thousands of dependent projects. The infamous left-pad incident and various breaking changes in popular packages have demonstrated how version mismanagement can disrupt the entire JavaScript ecosystem.
Enterprise software teams rely on SemVer for release planning, API deprecation timelines, and customer communication. A major version bump often triggers documentation updates, migration guides, and deprecation notices. This calculator helps you determine the correct next version before publishing, ensuring your versioning communicates the right information to every consumer of your software.
Whether you maintain a single open-source library or manage dozens of internal packages, the Semantic Versioning Calculator provides a quick reference for the version bump rules that keep your software ecosystem predictable and trustworthy. Use it alongside your CI/CD pipeline to validate version numbers before releases hit production.
The calculator applies the official SemVer 2.0.0 version bumping rules based on the selected bump type:
Major Bump (Breaking Change):
$$\text{MAJOR} \to \text{MAJOR} + 1, \quad \text{MINOR} \to 0, \quad \text{PATCH} \to 0$$
Example: 1.4.2 → 2.0.0. Both minor and patch reset to zero because the major version increment signals a completely new compatibility baseline.
Minor Bump (New Feature):
$$\text{MAJOR} \to \text{MAJOR}, \quad \text{MINOR} \to \text{MINOR} + 1, \quad \text{PATCH} \to 0$$
Example: 1.4.2 → 1.5.0. The patch resets because the new minor version establishes a fresh patch baseline.
Patch Bump (Bug Fix):
$$\text{MAJOR} \to \text{MAJOR}, \quad \text{MINOR} \to \text{MINOR}, \quad \text{PATCH} \to \text{PATCH} + 1$$
Example: 1.4.2 → 1.4.3. Only the patch number increments; no other fields change.
Breaking Change Flag:
$$\text{Is Breaking} = \begin{cases} 1 & \text{if bump\_type} = \text{major} \\ 0 & \text{otherwise} \end{cases}$$
This flag helps automated tools trigger additional workflows like generating migration guides or sending breaking change notifications.
The New Major/Minor/Patch values show your computed next version string. Verify that the bump type matches the actual nature of your changes: if you modified a public API signature, parameter order, or removed a feature, this is a major bump regardless of how small the code change feels.
The Is Breaking Change flag (1 or 0) indicates whether the new version signals backward incompatibility. When this is 1, downstream consumers using caret (^) ranges in their package managers will not automatically receive this update, protecting them from unexpected breakage.
If you are unsure about the correct bump type, err on the side of caution: when in doubt, bump major. It is far better to over-communicate breaking changes than to silently break consumer code with a minor or patch release.
Inputs
Results
Adding a new endpoint to a REST API is backward-compatible new functionality, warranting a minor bump. Version 2.3.7 becomes 2.4.0, with the patch resetting to zero.
Inputs
Results
Removing a public function, even if deprecated, is a breaking change. Version 3.12.1 becomes 4.0.0, with both minor and patch resetting. The breaking change flag is set to 1.
Semantic Versioning is a versioning scheme using the format MAJOR.MINOR.PATCH where each component has specific meaning. MAJOR increments for backward-incompatible changes, MINOR for backward-compatible new features, and PATCH for backward-compatible bug fixes. It was created by Tom Preston-Werner and is defined at semver.org.
Resetting minor and patch to zero signals a new compatibility baseline. Version 2.0.0 tells consumers that all bets are off relative to the 1.x series. The fresh numbering also prevents confusion, as 2.13.5 as a first major release would imply 13 feature additions and 5 patches that never actually happened in the v2 context.
A breaking change is any modification to the public API that could cause existing consumer code to fail. This includes: removing a function or endpoint, changing parameter types or order, renaming public methods, changing return value structures, removing configuration options, or changing default behavior. Even adding a required parameter to an existing function is breaking.
npm uses caret (^) and tilde (~) ranges: ^1.4.2 allows updates to 1.x.x (any minor/patch) while ~1.4.2 allows only 1.4.x (patch only). This means a correctly bumped major version will not be automatically installed for caret-range consumers, protecting them from breaking changes.
SemVer supports pre-release identifiers appended with a hyphen: 2.0.0-alpha.1, 2.0.0-beta.3, 2.0.0-rc.1. Pre-release versions have lower precedence than the associated release. This calculator focuses on the core MAJOR.MINOR.PATCH bumping logic; pre-release suffixes are typically managed by release tooling.
SemVer considers 0.x.x as initial development where anything may change at any time. The public API is not considered stable until 1.0.0. Start at 0.1.0 for new projects in active development, and release 1.0.0 when your API is stable and ready for production consumers.
SemVer encodes compatibility information (breaking/feature/fix), while Calendar Versioning (CalVer) encodes release dates (e.g., 2026.03). SemVer is preferred for libraries and APIs where backward compatibility matters. CalVer is used by projects like Ubuntu and pip where the release date is more meaningful than API stability.
Monorepo versioning can use either fixed mode (all packages share one version, like Angular) or independent mode (each package has its own version, like Babel). Tools like Lerna, Changesets, and Nx provide automated SemVer bumping based on conventional commit messages and dependency graphs.
Technically yes, but it is strongly discouraged. Skipping from 1.0.0 to 1.5.0 implies four feature releases that never existed, which is misleading. Each release should increment by exactly one in the appropriate field. The only common exception is skipping from 0.x directly to 1.0.0 to signal initial stable release.
Popular tools include: semantic-release (fully automated based on commit messages), standard-version (generates changelogs and bumps versions), Changesets (monorepo-friendly with PR-based workflow), release-please (Google's GitHub Action for automated releases), and commitizen (interactive commit message helper that feeds into automated versioning).
Roboculator Team
The Roboculator Team explains calculations, planning tools, and practical formulas in clear language for real-life situations.
How helpful was this calculator?
Be the first to rate!
