{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }}
{{ bumpLabel(computation.values.required_bump) }} floor {{ computation.values.coverage_label }} {{ computation.values.signal_count }} signal{{ computation.values.signal_count === 1 ? '' : 's' }}
Use the package, public API, service, or command-line artifact being versioned.
Use MAJOR.MINOR.PATCH with optional prerelease or build metadata.
A prerelease can stage work but does not replace the matching stable release.
Use the pre-1.0 convention only when maintainers and consumers already share that policy.
The strongest classified line sets the required floor; vague lines remain visible for maintainer review.
{{ sourceStatus }}
Keep the default for public API deprecations; use warning-only only for a documented external process.
The default is neutral and opening Advanced without edits leaves the verdict unchanged.

Minimum release decision

{{ computation.values.coverage_label }}
{{ computation.values.coverage_detail }}
{{ bumpLabel(computation.values.required_bump) }} required
  • {{ row.label }}{{ row.value }}

This browser-local classifier applies SemVer and Conventional Commit signals plus documented keyword heuristics. It cannot prove public API compatibility.

Correct the highlighted input before using the release decision.
LineBumpSignalConfidenceEvidenceChange and rationaleCopy
{{ row.line }}{{ bumpLabel(row.bump) }}{{ row.signal }}{{ row.confidence }}{{ row.evidence }}{{ row.change }} — {{ row.reason }}
GateStatusEvidenceNext actionCopy
{{ row.gate }}{{ row.status }}{{ row.evidence }}{{ row.action }}
Release Notes Generator Turn commits, pull requests, or release bullets into audience-ready Markdown with grouped changes, parser warnings, and publication checks.
Changelog Generator Turn release notes, changelog sections, or Conventional Commit subjects into grouped Markdown with SemVer signals and pre-publish checks.
Dependency Update Risk Analyzer Rank dependency updates by release movement, runtime exposure, security and test evidence to plan safer review and merge lanes for your project.
Release Cutover Window Calculator Budget a release cutover against its maintenance window, preserving rollback time while safely testing contingency and gate margin.

A version number becomes useful when it tells downstream users what kind of change to expect. Semantic Versioning, or SemVer, expresses that promise as MAJOR.MINOR.PATCH. The numbers describe compatibility with a declared public API, not the amount of code changed or the effort behind a release.

Change Normal bump What consumers should infer
Backward-incompatible public API change Major Existing integrations may need migration.
Backward-compatible public addition or deprecation Minor Existing use should continue, with new capability or advance notice of removal.
Backward-compatible bug fix Patch The documented public contract is intended to remain compatible.
Maintenance with no public behavior change No SemVer bump required A project may still publish a new version under its own release policy.

Public API means everything consumers are entitled to rely on. For a library, that may be functions, types, and return values. For a service or command-line program, it can also include request fields, response schemas, command flags, configuration keys, supported runtimes, file formats, or documented behavior. A large internal refactor may leave that contract intact, while removing one accepted field may break it.

A release often contains several kinds of work. The required bump is set by the strongest compatibility consequence, not by the most common line in the changelog. Ten fixes and one removed public method still require the bump that covers the removal.

Commit conventions can make the evidence clearer. Conventional Commits maps fix: to patch, feat: to minor, and either a ! marker or BREAKING CHANGE footer to major. Release notes written in ordinary language can carry the same meaning, but words alone remain imperfect evidence. A misleading commit type or an undocumented schema break can produce the wrong answer.

Version zero needs an explicit team convention. SemVer says 0.y.z is initial development and its public API should not be treated as stable. Some projects nevertheless use the next minor number for a breaking pre-1.0 change. That can be a workable policy only when maintainers, consumers, and automation already agree on it.

A text-based bump review is therefore a release gate, not proof of compatibility. The final decision should still be checked against the actual API diff, schema change, supported-platform policy, and migration plan.

How to Use This Tool:

Start with the released version and the change evidence that will accompany the next release.

  1. Enter the Package or API name and a valid Current version. A leading v is accepted as a tag prefix and removed for comparison.
  2. Add a Planned version to test a release candidate, or leave it blank to calculate only the minimum stable version.
  3. Choose the Version policy. Keep strict SemVer unless the project has a documented convention that maps breaking changes on 0.y.z to the next minor release.
  4. Paste one release-note bullet, commit subject, pull-request title, or API-diff note per line in Change list. Normalize the text when copied bullets or blank lines make the list noisy.
  5. Change Deprecation handling or Neutral maintenance only when the project has an established policy that differs from the defaults.
  6. Review the Release decision, then inspect medium- and low-confidence entries in the Signal ledger. Fix invalid versions or vague release lines before using the result as a gate.

Interpreting Results:

Bump covered means the planned version is higher than the current version and reaches at least the detected floor. Increase bump means it does not. A matching prerelease such as 2.8.0-rc.1 can stage a minor release, but it still sorts below stable 2.8.0.

  • Treat the required bump as a minimum. A higher valid bump covers a lower floor, though it may communicate more disruption than the changes warrant.
  • Use confidence labels to focus review. Explicit markers are stronger evidence than general wording, and an unclassified line is conservatively treated as patch-level.
  • Do not let the signal counts vote down a breaking change. The highest level wins even when it appears only once.
  • Confirm any major result against the real public API. A keyword match can raise a false alarm, and missing release text can hide a genuine break.

Technical Details:

SemVer precedence compares major, minor, and patch as integers. When those three values match, a prerelease has lower precedence than the corresponding stable version. Dot-separated prerelease identifiers compare in order, with numeric identifiers compared numerically and placed below non-numeric identifiers. Build metadata after + does not affect precedence.

Formula Core:

Each non-empty change line receives a level: none = 0, patch = 1, minor = 2, and major = 3. The release floor is the maximum of those levels.

Lrequired = max ( L1 , L2 , … , Ln )

Planned coverage also requires the planned version to sort above the current version and its numeric bump level to be at least the required level.

C = ( Vplanned > Vcurrent ) ∧ ( Lplanned ≥ Lrequired )

Rule Core:

Evidence Default level Important qualification
BREAKING CHANGE, BREAKING-CHANGE, or a Conventional Commit ! Major Explicit, high-confidence breaking signal.
Incompatible wording, removed public surface, or changed contract/schema/signature Major Changed-contract wording is medium confidence and needs API review.
Public deprecation Minor The warning-only option records it without raising the floor.
feat: or additive public capability wording Minor The addition must remain backward compatible.
fix:, perf:, security, regression, timeout, race, leak, or correction wording Patch The compatible-fix reading yields to any stronger signal.
Docs, tests, CI, style, chore, build, refactor, README, typo, or formatting wording None The optional patch-floor policy promotes neutral shipped maintenance.
No recognized signal Patch Low-confidence fallback until a maintainer confirms neutrality.

Suggested stable versions reset lower-order fields: major turns 2.7.4 into 3.0.0, minor produces 2.8.0, and patch produces 2.7.5. Under the optional pre-1.0 convention, a major signal on 0.7.4 becomes a minor floor and suggests 0.8.0.

The input is limited to 500 non-empty lines and 100,000 characters. Classification is deterministic for the same normalized text and policy choices, but the result remains a heuristic reading of prose rather than a source- or binary-compatibility analysis.

Privacy and Accuracy Notes:

The release text is processed in the current browser and is not sent to a server by this checker. Keep following the project’s handling rules for unreleased product names, vulnerability details, and private API changes.

  • Keyword rules cannot inspect source code, schemas, compiled interfaces, downstream consumers, or runtime behavior.
  • A leading v is accepted only as a tag prefix; it is not part of the SemVer value.
  • Build metadata never raises version precedence, and a prerelease does not equal its matching stable release.
  • Medium- and low-confidence classifications should be resolved before publishing the version.

References: