Semantic Version Bumper

Enter a current version (e.g., 1.4.7-beta.2) and click major, minor, patch, or prerelease to see the bumped value. The increment rules follow the SemVer 2.0.0 spec: major resets minor and patch to zero, minor resets patch, prerelease increments the trailing identifier.

A second pane lets you compare two versions and tells you which is newer, by how much, and whether the change is a breaking shift or backward-compatible. Useful when reviewing a Renovate PR or verifying that a dependency upgrade is what you think it is.

Build metadata after a `+` sign is preserved as opaque — it's ignored for ordering, exactly as the spec requires.

Semantic Versioning 2.0.0 defines version strings as MAJOR.MINOR.PATCH, with optional pre-release (after a hyphen) and build metadata (after a plus sign). Bump rules: a major bump increments MAJOR and resets MINOR and PATCH to zero. A minor bump increments MINOR and resets PATCH. A patch bump increments PATCH only. The tool implements these exactly per spec — no surprise behaviors, no opinionated extensions.

Worked example. Current version: 2.4.7-beta.3+build.55. Click "patch" → 2.4.8 (pre-release identifier and build metadata are dropped because they no longer describe this new version). Click "minor" from 2.4.7 → 2.5.0. Click "major" → 3.0.0. From 2.4.7-beta.3, click "prerelease" → 2.4.7-beta.4. From 2.4.7 (no prerelease), click "prerelease" → 2.4.8-0 (the patch bumps because there's no existing pre-release to extend). All of this matches what `npm version` does and what most release tooling expects.

The comparison side: SemVer ordering puts 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. Pre-release identifiers compare element-by-element: numeric identifiers compare as numbers (so 11 > 2), alphanumeric compare lexically. Pre-release versions sort below the corresponding stable version. Build metadata (anything after `+`) is ignored for ordering — versions that differ only in build metadata are considered equal by SemVer.

Where SemVer breaks down in the wild. Many projects don't follow it. Node.js itself uses calver-ish patterns for major releases. Some libraries bump major on tiny breaking changes; others let major sit at 0.x for years even after the API stabilizes (the spec says 0.x.y is unstable, but conventions vary). The tool implements the spec faithfully — if your project uses a different convention, the bump output may not match your team's expectations. That's a process problem, not a tool bug.