SemVer Bump Calculator

Semantic versioning gives version numbers meaning: the major number changes when incompatible behaviour is introduced, the minor number when functionality is added compatibly, and the patch number for compatible bug fixes. Teams that guess the next version often break that contract, shipping a breaking change as a patch and surprising everyone who upgrades. This calculator removes the guesswork. Enter the current version, choose the bump type, and it computes the next version exactly, including prerelease handling for versions that carry a prerelease tag. It is a small tool that protects the trust between a library author and everyone who depends on the library.

Quick Answer: Enter the current version, choose major, minor, patch or prerelease, and click Calculate Next Version to get the exact next number.

Free Online Tool

SemVer Bump Calculator

The exact next version for any bump, prereleases included.



How to Use the SemVer Bump Calculator

  1. Enter the current version in three part form, such as 1.2.3, with an optional prerelease tag.
  2. Choose the bump type that matches the change: major for breaking changes, minor for new features, patch for fixes.
  3. Click Calculate Next Version to compute the result under semantic versioning rules.
  4. Read the explanation line, which states which numbers changed and which reset to zero.
  5. Use the computed version for the release tag, the package version and the changelog heading.

Key Features

  • Major, minor and patch bumps with correct resetting of lower numbers to zero.
  • Prerelease handling: a prerelease tag is bumped numerically, or added cleanly to a patch release.
  • Clear explanation of each result, so the rule behind the number is visible, not just the number.
  • Input validation that rejects malformed versions instead of producing a misleading result.
  • Instant local calculation with no network use, suitable for release checklists.

Best Practices and Tips

  • Ask one question to pick the bump: does this break anyone, add anything, or only fix something. The answer maps directly to major, minor or patch.
  • Bump the minor version for new features even when they feel small, because users track feature availability by minor numbers.
  • Keep prerelease tags for test releases only, and drop the tag for the final release rather than bumping it again.
  • Update the changelog version heading to match the computed version, so tags, packages and notes never disagree.

Common Mistakes to Avoid

  • Shipping a breaking change as a minor or patch release, which breaks downstream projects that trusted the version contract.
  • Bumping only the patch number for a new feature, which hides the feature from users scanning minor versions.
  • Forgetting to reset lower numbers after a major or minor bump, producing versions such as 2.3.4 after a major bump from 1.2.3.

Frequently Asked Questions

What do the three numbers mean?

The first number is the major version, which changes for incompatible API changes. The second is the minor version, which changes when functionality is added in a backwards compatible way. The third is the patch version, which changes for backwards compatible bug fixes. Together they let users judge upgrade risk at a glance.

What happens to lower numbers on a bump?

A major bump resets minor and patch to zero, and a minor bump resets patch to zero. This rule keeps versions ordered: a major release of 2.0.0 always follows any 1.x version, and a minor release of 1.3.0 always follows any 1.2.x version.

How are prerelease versions handled?

A prerelease tag marks a version that is not yet final, such as a release candidate. Bumping a prerelease version increments its numeric suffix when one exists, and a prerelease bump on a stable version moves to the next patch with a starting prerelease tag, so test releases stay ordered before the final release.

Is 0.x special in semantic versioning?

Yes, in practice. Before version 1.0.0, anything may change at any time, and the usual contract is weaker. This calculator still applies the same arithmetic to 0.x versions, but teams should treat pre 1.0 releases as inherently unstable regardless of the bump type.

Related Tools