Loading page
About this tool
Answer a few questions about your change and get the correct major, minor or patch bump per the SemVer 2.0.0 spec.
The Semver Bump Decision Helper answers the question 'is this release a major, minor or patch?' by mapping a short checklist about your change onto the Semantic Versioning 2.0.0 rules: major for incompatible API changes (item 8), minor for backwards-compatible features and deprecations (item 7), patch for compatible bug fixes (item 6). It also handles the 0.x special case, where the spec allows anything to change and the ecosystem signals breakage in the minor digit. Library maintainers get the exact next version number computed from their current one, including pre-release finalisation.
Open Semver Bump Decision Helper on AltFTool — it loads instantly in your browser.
Type the version you last published, such as 1.4.2 or 0.4.2, into Current released version.
Under What does this release contain? tick the lines that apply - Removed or renamed anything public, Deprecated public API (still works, now warns), Fixed a bug without changing the documented contract - and tick the stable box to go straight to 1.0.0.
Read the Next version headline with the Recommended bump, Spec rule and Major version zero (0.x) rows naming the SemVer 2.0.0 item behind it, then press Copy result.
Every recommendation names the exact SemVer 2.0.0 item (3, 4, 5, 6, 7 or 8) that drives it.
Applies the major-version-zero convention: breaking changes bump minor, additions bump patch.
Turns 1.4.2 plus your answers into the literal next version, finalising pre-release tags correctly.
Whenever you make any backwards-incompatible change to the public API — removing or renaming exports, changing documented behaviour or types, or raising platform requirements. SemVer 2.0.0 item 8 makes this mandatory even for tiny breaking changes; the size of the change is irrelevant, only its compatibility.
Minor, at minimum. SemVer item 7 explicitly states the minor version must be incremented if any public API functionality is marked as deprecated, even though the API still works. The actual removal later is the major bump.
SemVer item 4 says that in major version zero anything may change at any time, so the spec imposes no rule. The universal convention — which npm's caret ranges assume, since ^0.4.2 excludes 0.5.0 — is to put breaking changes in the minor digit and everything else in patch. When the API stabilises, item 5 says release 1.0.0.
If you release it, yes: SemVer item 3 forbids modifying the contents of a released version, so any new release needs a new number — a patch bump when nothing observable changed. A dependency update becomes minor or major only if it changes your own public behaviour or raises requirements for your consumers.