When should I bump major?

When you change a public-API contract in a way that could break consumers: removed methods, renamed methods, changed signatures, changed return types, changed behavior of existing methods, removed configuration options, changed default behavior. Even one such change requires a major bump. Adding new methods alongside the old (without changing the old) is minor.

What's the difference between alpha, beta, and rc?

By convention: alpha = early, possibly unstable, API still in flux. beta = feature-complete but bugs expected, API mostly stable. rc (release candidate) = ready to ship, only blocking bugs would prevent release. Pre-1.0 software often skips these distinctions; mature projects use them more carefully. Versioning: 1.0.0-alpha.1 → 1.0.0-alpha.2 → ... → 1.0.0-beta.1 → ... → 1.0.0-rc.1 → 1.0.0.

What's calendar versioning (CalVer)?

Versioning by date instead of semantic meaning: 23.10.0 = released in October 2023. Used by Ubuntu, pip's own packaging, Twisted, JetBrains tools. Best when 'compatibility breakage' isn't a coherent concept (the user always gets the latest), or when release timing matters more than API stability. Different from semver; pick the right one for your project.

What's the difference between ^ and ~ in package.json?

^1.2.3 = compatible up to but not including 2.0.0 (allows minor and patch updates). ~1.2.3 = compatible up to but not including 1.3.0 (allows patch updates only). ^ is the npm default; it's correct when the maintainer follows semver. ~ is more conservative; some teams use it when they don't trust upstream semver. Both rely on the maintainer correctly distinguishing minor vs major changes.

What happens if I publish a major change as patch?

Downstream applications using `^1.2.3` auto-update to your patch and break unexpectedly. CI fails, customers report bugs, the maintainer (you) gets blamed. Best practices: publish the broken patch, then immediately deprecate it via npm deprecate, then publish the proper major bump. Better: don't make this mistake. The semver-major bump exists precisely so consumers can opt-in to breaking changes.

What about 0.x.y versions?

Pre-1.0 versions are 'unstable by convention' — many projects bump 0.X for breaking changes (treating MINOR as MAJOR). Once you hit 1.0, you commit to semver semantics. This is why projects often delay 1.0 release: it's a stability promise, not just a number. npm packages still in 0.x are common; Rust crates almost always.

Developer Utilities · Free tool

Semver Bumper

Bump a semantic version across major, minor, or patch levels instantly online. See exact changes and pick the right increment for your release free.

Updated June 2026

Current version

Prerelease identifier

Next version

1.2.4

npm version 1.2.4 --no-git-tag-version

Found this useful?Email Buy Me a Coffee

What it does

Bump a semantic version number to its next major, minor, or patch — and see the next prerelease (alpha/beta/rc) and dev versions for advanced workflows. Most importantly, the tool surfaces the compatibility contract behind each choice so you don’t accidentally break downstream consumers.

Semantic versioning (semver) was formalized by Tom Preston-Werner (GitHub co-founder) in 2010 as semver.org, codifying conventions that were already spreading informally. The format is MAJOR.MINOR.PATCH:

MAJOR: incompatible API changes (breaking changes to public interfaces).
MINOR: backward-compatible new functionality.
PATCH: backward-compatible bug fixes.

Optional pre-release identifier: 1.2.3-alpha.1, 1.2.3-beta.2, 1.2.3-rc.1. Optional build metadata: 1.2.3+abc123 (allowed but ignored by version-comparison logic per spec). Most package managers (npm, pip, Cargo, Maven) require strict semver compliance for dependency resolution to work — version-range operators like ^1.2.3 (caret = compatible MAJOR), ~1.2.3 (tilde = compatible MINOR), and >=1.2.3 <2.0.0 all rely on the MAJOR-MINOR-PATCH semantics being honored.

The most common semver mistake is under-bumping after a breaking change: you fix something but the fix changes the public API, and you bump PATCH instead of MAJOR. Now ^1.2.3 dependents auto-update and break. When in doubt, bump MAJOR — it’s less painful for users to consciously update than to be silently broken.

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/semver-bumper" width="100%" height="720" frameborder="0" loading="lazy" title="Semver Bumper" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

How to use it

Enter your current version (e.g. 1.2.3 or 2.0.0-beta.5).
Pick the bump type: major (X.0.0), minor (1.Y.0), patch (1.2.Z), prerelease (1.2.3-alpha.1 or increment the prerelease counter), or build (no version change, add metadata).
Read the next version. The tool also explains the compatibility contract — what your downstream consumers can expect.
If you're unsure whether your change is breaking: did you remove a public method, change a method signature, change behavior, or change return types? Yes = MAJOR. Did you add new things only? = MINOR. Pure bug fix preserving existing behavior? = PATCH.
After publishing, tag the git commit with the new version (`git tag v1.2.3`) so you have an immutable reference point.

When to use this tool

Releasing a new version of a library or package — picking the right bump avoids downstream breakage.
Teaching semver to new contributors who haven't internalized when to bump major vs minor.
Publishing prereleases (alpha / beta / rc) where the format is more nuanced.
Reviewing a PR's version bump for correctness — does the change actually warrant the bump claimed?

When not to use it

Internal services that don't have downstream consumers — semver is for public APIs / libraries / packages. For internal date-versioned releases, use calendar versioning (CalVer): YYYY.MM.DD or 23.10.0.
Browser apps where users don't pin versions — they always get the latest, so bumping is more about marketing than compatibility (1.0 vs 2.0 'rebrand').
Operating systems and large platforms with their own conventions (macOS 14, Windows 11, iOS 17) — those are CalVer-ish or marketing-driven.

Common use cases

Educational use — demonstrating the underlying concept
Onboarding a colleague who needs the same calculation/conversion
Verifying a number or output before passing it on
Quick use during a typical workday

Frequently asked questions

When should I bump major?: When you change a public-API contract in a way that could break consumers: removed methods, renamed methods, changed signatures, changed return types, changed behavior of existing methods, removed configuration options, changed default behavior. Even one such change requires a major bump. Adding new methods alongside the old (without changing the old) is minor.
What's the difference between alpha, beta, and rc?: By convention: alpha = early, possibly unstable, API still in flux. beta = feature-complete but bugs expected, API mostly stable. rc (release candidate) = ready to ship, only blocking bugs would prevent release. Pre-1.0 software often skips these distinctions; mature projects use them more carefully. Versioning: 1.0.0-alpha.1 → 1.0.0-alpha.2 → ... → 1.0.0-beta.1 → ... → 1.0.0-rc.1 → 1.0.0.
What's calendar versioning (CalVer)?: Versioning by date instead of semantic meaning: 23.10.0 = released in October 2023. Used by Ubuntu, pip's own packaging, Twisted, JetBrains tools. Best when 'compatibility breakage' isn't a coherent concept (the user always gets the latest), or when release timing matters more than API stability. Different from semver; pick the right one for your project.
What's the difference between ^ and ~ in package.json?: ^1.2.3 = compatible up to but not including 2.0.0 (allows minor and patch updates). ~1.2.3 = compatible up to but not including 1.3.0 (allows patch updates only). ^ is the npm default; it's correct when the maintainer follows semver. ~ is more conservative; some teams use it when they don't trust upstream semver. Both rely on the maintainer correctly distinguishing minor vs major changes.
What happens if I publish a major change as patch?: Downstream applications using `^1.2.3` auto-update to your patch and break unexpectedly. CI fails, customers report bugs, the maintainer (you) gets blamed. Best practices: publish the broken patch, then immediately deprecate it via npm deprecate, then publish the proper major bump. Better: don't make this mistake. The semver-major bump exists precisely so consumers can opt-in to breaking changes.
What about 0.x.y versions?: Pre-1.0 versions are 'unstable by convention' — many projects bump 0.X for breaking changes (treating MINOR as MAJOR). Once you hit 1.0, you commit to semver semantics. This is why projects often delay 1.0 release: it's a stability promise, not just a number. npm packages still in 0.x are common; Rust crates almost always.

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →