{{ 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 release rows available
Paste release notes or commit subjects to classify the required bump.
Tags: Devtools, Diagnostics
Release Notes Generator Turn commit lines, PR lists, or release bullets into grouped Markdown notes with parser warnings, readiness gates, and review ledgers.
.env File Generator Generate reviewed .env and .env.example files from pasted rows or a small text file, with duplicate checks, quote guidance, and masked secret previews.
Changelog Generator Draft a release changelog from notes, Markdown sections, or Conventional Commit subjects with category grouping, SemVer review, and copy-ready Markdown.
Bug Report Generator Draft a tracker-ready bug report with Markdown, triage fields, a reproducibility checklist, and local privacy-pattern warnings before filing.
Customize
Advanced
:

Version numbers are small, but they carry a compatibility promise. Semantic Versioning, usually shortened to SemVer, gives that promise a three-part shape: MAJOR.MINOR.PATCH. The first number changes when existing users may have to change their code, the second changes when compatible public capability is added, and the third changes when compatible fixes are shipped.

The hard part is deciding which release evidence belongs in which part of the number. A short changelog can mix a new option, a timeout fix, a documentation update, and a removed legacy field. Those changes should not be averaged. SemVer review uses the strongest compatibility signal as the floor because one breaking public API change can outweigh many harmless maintenance lines.

Bump level Typical evidence Compatibility meaning
Major Removed method, renamed response field, dropped runtime, incompatible schema, or explicit breaking-change note. Consumers may need migration before upgrading safely.
Minor New public option, compatible feature, added endpoint, or public deprecation notice. Existing consumers should keep working, while new capability or migration warning appears.
Patch Bug fix, security fix, performance correction, timeout repair, regression fix, or other compatible correction. The public contract is intended to stay the same.
No bump Docs, tests, formatting, CI, build notes, or other maintenance with no shipped behavior change. SemVer itself does not require a bump, though a project may still tag one by policy.
SemVer bump floor flow Release evidence is classified into bump levels, the strongest level sets the required floor, and the planned version is checked against that floor. Release text notes and commits Signals major to none Required floor strongest wins Planned version covered or low major > minor > patch > none

A public API is broader than a library method. It can include a command-line flag, configuration field, event name, response shape, file format, supported runtime, database schema, or service contract that users rely on. Private refactoring may not affect the version floor at all, while a single renamed public field can force a major release.

Major version zero needs a written project policy. SemVer treats 0.y.z as initial development, where the public API may change quickly. Many teams still use a next-minor bump for breaking changes before 1.0.0, but that convention should be visible to consumers and release automation before it changes a tag.

Text evidence is useful for audit, but it is not a compatibility test. A changelog line can be too vague, a commit type can be wrong, and a public contract can break without using the word breaking. The final release number still depends on maintainer review of the real API surface.

How to Use This Tool:

Use the checker when release notes, commit subjects, pull request titles, or API diff bullets need a consistent SemVer bump floor before a release tag is cut.

  1. Enter the Package or API name so the result tables, JSON, and exports identify the release being reviewed.
  2. Set Current version. A leading v tag prefix is normalized, but the remaining version must match a valid SemVer core.
  3. Enter Planned version when you want coverage verification. Leave it blank if you only need the required bump and suggested next stable version.
  4. Choose Version policy. Strict SemVer public API keeps breaking signals as major; 0.x breaking changes use next minor maps breaking signals on 0.y.z releases to the next minor.
  5. Paste one item per line in Change list. Load sample fills realistic starter lines, and Normalize trims bullets and blank lines before classification.
  6. Open Advanced only when your project treats public deprecations or neutral maintenance differently. The defaults make deprecations minor and leave docs or maintenance lines at no bump.
  7. If Review version inputs appears, fix the version fields before trusting coverage. Then read Bump Verdict, Change Signal Ledger, Release Checklist, Bump Signal Ladder, and JSON.

Interpreting Results:

The required bump is a minimum. Major outranks minor, minor outranks patch, and patch outranks neutral rows only when no stronger signal is present. A chart with many patch rows and one breaking row still points to a major floor because severity beats count.

  • Bump Verdict is the main coverage check. Compare the detected signal, required floor, suggested next version, planned bump, coverage verdict, confidence label, and selected policy.
  • Change Signal Ledger shows how each line was classified. Low-confidence rows are review prompts, especially when the line describes a shipped change without clear SemVer wording.
  • Release Checklist calls out invalid versions, under-bumped planned versions, breaking-change communication, deprecation sequencing, and manual API review needs.
  • Bump Signal Ladder explains the mix of major, minor, patch, and no-bump evidence. Use it to audit the release text, not to outvote the strongest signal.
  • JSON mirrors the result data for release notes, audit records, or automation experiments. Check the verdict in the visible table before wiring it into a publish step.

Technical Details:

The version parser accepts a numeric SemVer core with optional prerelease and build metadata. Major, minor, and patch are compared numerically. When the numeric core is equal, a prerelease sorts below the matching normal release, so 2.8.0-rc.1 stages work toward 2.8.0 but does not fully replace the stable version. Build metadata after + is preserved for display but does not change precedence.

Change classification happens one non-empty line at a time. Conventional Commit markers such as feat:, fix:, perf:, !, BREAKING CHANGE, and BREAKING-CHANGE are understood, along with release-note wording about removed public surfaces, changed contracts, deprecations, compatible additions, fixes, security work, and neutral maintenance.

Formula Core

The required floor is the maximum level across classified change lines, where none is 0, patch is 1, minor is 2, and major is 3.

Lrequired = max ( L1 , L2 , ... , Ln ) covered = ( Vplanned > Vcurrent ) ∧ ( Lplanned ≥ Lrequired )

Here L is a bump level and V is SemVer precedence. Coverage requires the planned version to sort above the current version and represent at least the required numeric bump.

Rule Core

Detected signal Evidence pattern Default bump Review note
Breaking API change BREAKING CHANGE, BREAKING-CHANGE, or a Conventional Commit ! marker. Major High-confidence signal that existing consumers may need migration.
Removed public surface Remove, drop, or delete wording near API, endpoint, method, field, parameter, option, event, runtime, support, or legacy terms. Major Removal is treated as backward-incompatible unless maintainer review proves otherwise.
Changed contract Rename or change wording near signature, contract, schema, request, response, field, parameter, method, endpoint, route, or type. Major Medium confidence because some contract changes are compatible and some are not.
Deprecation notice Deprecation-related wording. Minor The warning-only policy can record deprecations outside the bump calculation.
Feature or additive public capability feat:, or add, introduce, support, new, or optional wording near public API terms. Minor Backward-compatible public functionality moves the minor number and resets patch to zero.
Bug, security, or performance fix fix:, perf:, security, CVE, timeout, race, leak, stability, regression, hotfix, or 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, workflow, or similar wording. No bump The patch-floor policy can promote these rows when every shipped artifact change gets a patch.
Unclassified shipped change Non-empty line with no stronger SemVer signal. Patch Low-confidence fallback. Review before tagging.

Version Coverage Examples

Current Required floor Suggested stable version Coverage reading
2.7.4 Patch 2.7.5 2.7.5 covers it; 2.7.4 does not move forward.
2.7.4 Minor 2.8.0 2.8.0 covers it; 2.7.5 under-bumps.
2.7.4 Major 3.0.0 3.0.0 covers it; 2.8.0 does not.
0.7.4 Major signal with 0.x minor-break policy 0.8.0 The selected policy maps the breaking signal to the next minor.
2.8.0-rc.1 Patch to stable 2.8.0 The normal release sorts above the prerelease with the same numeric core.

For a concrete mix, feat(api): add refund status filter produces a minor signal, fix(client): retry 429 responses produces a patch signal, and BREAKING CHANGE: remove legacy order field produces a major signal. The required floor is major because the strongest line wins.

Privacy and Accuracy Notes:

The release text is classified in the browser. That keeps draft changelog lines and unreleased API notes on the current device, but it does not replace the team's own handling rules for sensitive release material.

  • Keyword classification cannot inspect the real public API, run binary compatibility checks, compare schemas, or test downstream consumers.
  • Low-confidence ledger rows should be reviewed before they decide a release number.
  • A leading v is treated as a tag prefix convenience, not as part of the SemVer value.
  • Build metadata does not change precedence and should not be used to cover a required bump.

Advanced Tips:

  • Use 0.x breaking changes use next minor only when the project intentionally treats pre-1.0 breaking changes as minor releases.
  • Keep Deprecations require minor bump when the deprecation is public. Switch to warning-only only if deprecation records live outside release versioning.
  • Use Treat neutral shipped changes as patch for distribution policies that version every published artifact change, even when SemVer does not require it.
  • Review Changed contract rows carefully. A renamed test fixture may be neutral, but a renamed response field can be breaking.
  • Download or copy the Change Signal Ledger before release review so the final tag decision can cite the exact lines that raised the floor.

Worked Examples:

Patch-only correction

From 2.7.4, a change list with fix(timeout): correct timeout message and no stronger signal requires a patch. A planned 2.7.5 should show covered, while 2.7.4 or a lower version should fail the coverage check.

Compatible feature

From 2.7.4, feat(client): add retry option creates a minor floor. A planned 2.8.0 covers it because the minor number increases and patch resets to zero. A planned 2.7.5 remains too low even if every test passes.

Breaking contract with a pre-1.0 policy choice

From 0.7.4, feat(api)!: change order response shape is a major-level signal. Under strict public API policy, it requires a major bump. Under the 0.x minor-break policy, the required floor maps to 0.8.0, and the verdict notes that policy mapping.

FAQ:

Does a major result prove the release is breaking?

No. It means the visible text contains a major-level signal. Confirm the actual public API impact before tagging.

Why does a prerelease not fully cover the bump?

A prerelease such as 2.8.0-rc.1 sorts below the normal 2.8.0 release. It can stage the release, but the stable version is the full coverage point.

What should I do with documentation-only changes?

Leave the neutral maintenance policy at no bump when docs do not change public behavior. Choose the patch-floor policy only if your release process tags every shipped artifact change.

Why is my planned version invalid?

The version must use a valid SemVer core such as 1.2.3, with optional prerelease and build metadata. Fix Current version or Planned version before trusting the coverage verdict.

Can I paste a full changelog?

Yes, but the checker classifies one non-empty line at a time. Use Normalize to trim bullets and blank lines, then review low-confidence ledger rows for headings or vague entries that need maintainer judgment.

Glossary:

Public API
The documented behavior, functions, fields, commands, options, formats, or contracts that consumers are expected to depend on.
Required floor
The smallest SemVer bump level that covers the strongest detected change signal.
Prerelease
A version suffix such as -alpha.1 or -rc.1 that sorts below the matching normal version.
Build metadata
A + suffix that carries build information without changing SemVer precedence.
Neutral maintenance
Docs, tests, formatting, build, or workflow changes that do not imply a public behavior change by default.
Coverage verdict
The comparison between the required floor and the planned version's actual bump level.

References: