Semantic Release Preview

Given a current version and conventional-commit list, suggest the next version.

Overview

Enter a current version and paste a list of conventional commits since the last release; the tool suggests the next version following Semantic Versioning and Conventional Commits rules - patch for fix:, minor for feat:, major for any commit with ! or a BREAKING CHANGE: footer.

It's for maintainers running release-please, semantic-release, or any automated versioning pipeline who want to preview the next bump before pushing. Reach for it when validating a release PR's diff, deciding whether to land a feature now or wait for a major-version window, or training contributors on what their commit type means.

How it works

Semantic Versioning 2.0.0 declares three components: MAJOR.MINOR.PATCH. The bump rule for Conventional Commits is:

Any commit with ! after the type/scope or a BREAKING CHANGE: footer -> major bump.
Otherwise, any commit with type feat -> minor bump.
Otherwise, any commit with type fix -> patch bump.
Otherwise, no bump (chores, docs, refactors are version-neutral by default).

The tool parses each commit line, classifies it, and reports the highest required bump. It mirrors the behaviour of semantic-release and release-please for predictable results.

Examples

Current 1.2.3 + a single fix:

fix: handle null response
-> next: 1.2.4

Current 1.2.3 + a feat:
```
feat: add /api/v2/users
-> next: 1.3.0
```

Current 1.2.3 + a breaking change:

feat(api)!: rename /users to /accounts
-> next: 2.0.0

Mixed:

feat: add filter
fix: typo
chore: bump deps
-> next: 1.3.0 (highest bump wins)

FAQ

Should chores trigger a release?

By default no - chore, docs, style, refactor, test don't bump versions. Some teams elect to release on refactor too; configure your release tool accordingly.

What about pre-1.0 versions?

SemVer treats 0.x as unstable - breaking changes commonly bump the minor version (0.1.x -> 0.2.0) rather than the major. Many release tools follow this convention for < 1.0.0.

Do revert: commits bump?

A revert should match the original change's bump level - if you reverted a feat, you're reverting a minor. Most tools treat revert as a patch by default; check your tool's docs.

Why is the bump higher than I expected?

A single BREAKING CHANGE footer anywhere in the commit list forces a major bump. Inspect each commit for ! markers or BREAKING CHANGE paragraphs.

Try Semantic Release Preview