{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
{{ field.help }}
Use one change per line; Conventional Commit markers like feat:, fix:, !, and BREAKING CHANGE are understood.
{{ changeMetaLabel }}
Paste release notes, commit subjects, or API diff bullets.
{{ field.help }}
{{ header }} Copy
{{ cell.value }} {{ displayCell(cell) }}
No rows for the current input.
Tags: Devtools, Diagnostics
Export to PDF Fullscreen
Customize
Advanced
:

Semantic Versioning turns a release number into a compatibility signal. The major, minor, and patch positions tell dependents whether a release is expected to break existing use, add compatible capability, or correct behavior without changing the public API.

A bump review is useful before a tag is cut because release notes, commit subjects, pull request titles, and API diff notes often mix several kinds of change. One breaking line should outweigh a long list of small fixes. A compatible feature should require more than a patch. Documentation and build maintenance may not require a public package bump unless the team deliberately treats every shipped artifact change as version-worthy.

Change lines flowing through signal classification, required bump floor, planned-version coverage, and major minor patch none ranking.

Semantic Versioning depends on a clear public API. A private refactor can be huge and still have no public version impact, while one removed field or renamed endpoint can force a major release. Major version zero also needs care: it signals initial development, so teams often decide how strictly to treat breaking changes before the API is stable.

A version bump check cannot decide whether the code is actually compatible. It can organize the visible release evidence so maintainers know which rows require human API review before the planned version is trusted.

Technical Details:

SemVer precedence starts with the numeric core: major, minor, then patch. Prerelease identifiers sort below the matching normal version, and build metadata does not change precedence. That means 2.8.0-rc.1 can stage work for 2.8.0, but it is still lower than the final stable release.

The release decision is a floor, not a vote. Each change line receives a bump level, and the strongest level becomes the required floor. A major signal beats minor, minor beats patch, and patch beats none. The planned version must be higher than the current version and at least as large as that floor before the coverage verdict can be considered covered.

Rule Core:

The checker classifies one normalized change line at a time. Bullets and numbered prefixes are stripped before keywords and Conventional Commit markers are tested.

Change Signal Detected From Default Bump Review Meaning
Breaking API change BREAKING CHANGE, BREAKING-CHANGE, or a Conventional Commit ! marker. Major Existing consumers may need migration before the release is safe to adopt.
Compatibility break Words such as incompatible or breaking, or removal of a public API surface such as endpoint, method, field, option, runtime, or legacy support. Major The wording points to a backward-incompatible public contract change.
Changed contract Rename or change wording near signature, schema, response, request, parameter, route, type, or endpoint. Major The row is medium-confidence because some contract changes are compatible and some are not.
Deprecation notice Deprecation-related wording. Minor SemVer treats public API deprecation as a minor release before later removal, unless the warning-only policy is selected.
Feature or additive public capability feat:, or add, introduce, support, new, optional wording near public API terms. Minor Backward-compatible capability should reset patch to zero in the next minor version.
Bug, security, or performance fix fix:, perf:, or fix, security, timeout, regression, race, leak, stability, and similar correction wording. Patch A compatible correction belongs in a patch release unless another row raises the floor.
Neutral maintenance docs, test, ci, style, chore, build, README, typo, formatting, or workflow wording. No bump Neutral rows do not force a bump unless the patch-floor policy is selected.
Unclassified shipped change A non-empty line with no stronger SemVer signal. Patch The result is low-confidence and should be reviewed before release tagging.

Version and Policy Boundaries:

Version comparison follows strict SemVer core syntax after an optional leading v tag prefix is removed for convenience. Planned versions are checked against both precedence and bump size.

Boundary How It Is Handled Result Effect
Version syntax Accepts MAJOR.MINOR.PATCH with optional prerelease and build metadata; leading zeroes in numeric core fields are rejected. Invalid current or planned versions appear under Review version inputs.
Leading v A tag-style prefix such as v2.7.4 is normalized to 2.7.4. The JSON output records a SemVer warning while comparison uses the normalized value.
Major version zero Strict SemVer public API keeps breaking changes as major; 0.x breaking changes use next minor maps a raw major signal to minor when current major is zero. Required floor can be lower than Detected signal under the 0.x policy.
Deprecation policy Deprecations require minor bump treats deprecation rows as minor; Deprecations are warning-only notes treats them as no bump. The same deprecation line can either raise the required floor or remain advisory.
Neutral-line policy Neutral documentation, test, build, and maintenance rows default to no bump, or to patch when the patch-floor option is selected. Required floor changes from none to patch for neutral-only shipped changes.
Prerelease planned version A planned prerelease on the required core version is lower than the stable version. Coverage verdict becomes Prerelease only until the stable version is planned.

The result views are derived from the same classified change set: Bump Verdict summarizes the floor and coverage, Change Signal Ledger shows row evidence, Release Checklist turns risk into release-review actions, Bump Signal Ladder counts signal classes, and JSON exposes the structured result.

Everyday Use & Decision Guide:

Start with the artifact name, the current version, and the planned version you expect to tag. Leave Planned version blank when the first question is only what bump the change list requires; the result will still calculate Suggested next.

Paste one release note, Conventional Commit subject, pull request title, or API diff note per line in Change list. Use Normalize when the paste contains bullets, numbering, or tag-style versions. The line count badge should match the number of meaningful changes you expect to classify.

  • Use Strict SemVer public API when the project has a stable public API and breaking changes should require the next major version.
  • Use 0.x breaking changes use next minor only for early-stage releases where the team deliberately maps breaking signals to the next minor version.
  • Keep Deprecations require minor bump when deprecation notices ship with the public API release.
  • Use Treat neutral shipped changes as patch only when the project requires a patch version for documentation, build, or maintenance-only shipped artifacts.
  • Open Change Signal Ledger before trusting a low-confidence or medium-confidence result.

A covered result does not prove the release notes are complete or that the public API really remains compatible. It means the planned version is high enough for the visible change signals and selected policies. Review rows labeled Changed contract, Unclassified shipped change, or Manual API review against the actual diff before tagging.

After the first pass, work from Release Checklist. If Planned bump coverage says increase the bump, change the planned version before the release candidate is promoted.

Step-by-Step Guide:

Move from version syntax to change evidence, then use the verdict and ledger together.

  1. Enter Package or API name so the Bump Verdict row identifies the release artifact being checked.
  2. Enter Current version. If Review version inputs says the current version must be valid SemVer, fix the core version before reading the verdict.
  3. Enter Planned version when you want coverage verification, or leave it blank when you only need Suggested next.
  4. Choose Version policy. For 0.x releases, confirm whether a raw breaking signal should stay major or map to next minor.
  5. Paste the Change list, then use Normalize if bullets or numbered lines should be cleaned before classification.
  6. Open Advanced only when Deprecation handling or Docs and maintenance lines should differ from the defaults.
  7. Read the summary and Bump Verdict. Required floor, Suggested next, Planned bump, and Coverage verdict should tell the same release story.
  8. Open Change Signal Ledger for the exact line evidence. Review low-confidence rows before relying on Confidence.
  9. Use Release Checklist, Bump Signal Ladder, and JSON after the ledger looks right, so downstream evidence is based on corrected inputs.

Interpreting Results:

Read Coverage verdict first, then confirm the rows behind it. Bump covered means the planned version is higher than the current version and covers the required floor. Increase bump, Bump missing, Prerelease only, and version-input errors should stop the release until the version or evidence is corrected.

Required floor is the policy-adjusted answer. Detected signal shows the raw strongest signal from the change list. Those can differ under the 0.x breaking-change policy, so do not assume the raw signal and final floor always match.

Result Cue What It Means What to Verify
Bump covered The planned version meets or exceeds the required SemVer floor. Check Change Signal Ledger for low-confidence or medium-confidence rows.
Increase bump The planned version is higher than current but still below the required floor. Use Suggested next or a higher compatible version before release.
No bump required No SemVer-affecting line was detected under the selected policies. Confirm neutral maintenance lines did not hide a behavior change.
Prerelease only The planned version is a prerelease of the required stable core. Use the stable core version for final release coverage.
Needs maintainer review At least one row has low-confidence classification. Compare the row text with the real public API diff before tagging.

The Bump Signal Ladder chart is best for explaining the mix of change signals. Use it as a summary, then return to Change Signal Ledger for the exact line, evidence, and reason behind each count.

Worked Examples:

Feature release covered by a minor bump. With Current version set to 2.7.4, Planned version set to 2.8.0, and change lines feat(client): add retry option to createOrder, fix(timeout): correct timeout message, and docs(readme): update migration example, Bump Verdict should show Detected signal as Minor, Required floor as Minor, Suggested next as 2.8.0, and Coverage verdict as Bump covered.

Breaking signal under an early 0.x policy. A project at 0.4.2 with Planned version set to 0.5.0 and Version policy set to 0.x breaking changes use next minor can classify feat(api)!: remove legacy order route as a raw major signal while still setting Required floor to Minor. Change Signal Ledger should still show the breaking evidence, and Bump Verdict should explain that policy mapped the floor.

Patch plan below a breaking removal. If Current version is 1.2.3, Planned version is 1.2.4, and the change list says remove legacy webhook field, the ledger treats the row as a removed public surface. Suggested next becomes 2.0.0, and Coverage verdict becomes Increase bump.

Invalid version before review. A current version such as 2.01.0 fails SemVer syntax because the minor field has a leading zero. The page shows Review version inputs and the summary says to check versions; fix the version string before using Required floor, Planned bump, chart counts, or JSON in release evidence.

FAQ:

Why did a breaking change require minor instead of major?

That happens only when the current version has major number 0 and Version policy is set to 0.x breaking changes use next minor. Detected signal keeps the raw major evidence while Required floor shows the policy-adjusted floor.

Can I leave the planned version blank?

Yes. A blank Planned version skips coverage verification and still reports Suggested next. Add the planned version when you want Coverage verdict to confirm the release number.

Why did a documentation line count as patch?

Docs and maintenance lines may be set to Treat neutral shipped changes as patch. With the default neutral policy, documentation, test, CI, style, chore, and build rows do not force a bump unless another line changes behavior.

Why does a prerelease not fully cover the bump?

SemVer gives a prerelease lower precedence than the matching stable version. A planned value such as 2.8.0-rc.1 stages the required core but remains Prerelease only until 2.8.0 is planned for the final release.

Does the change list get uploaded for analysis?

No backend upload is used for the checked workflow. The release text you paste is classified in the page, then shown through the verdict, ledger, checklist, chart, and JSON views.

Glossary:

Public API
The documented or enforced surface that consumers rely on, such as methods, endpoints, fields, options, schemas, or runtime support.
SemVer core
The MAJOR.MINOR.PATCH part of a version before prerelease or build metadata.
Prerelease
A hyphen suffix such as -rc.1 that sorts below the matching stable version.
Build metadata
A plus suffix such as +build.5 that is valid SemVer text but ignored for precedence.
Required floor
The smallest SemVer bump needed after the change signals and selected policies are applied.
Planned bump
The bump level implied by comparing the planned version with the current version.
Neutral maintenance
Documentation, test, CI, style, chore, build, or similar lines that do not automatically imply public behavior change.

References: