Versioning

brel never asks you what the next version is — it derives it from your git history using Conventional Commits and SemVer.

The algorithm

When you run brel release-pr (or brel next-version / brel changelog):

1. brel finds the highest stable SemVer tag that matches release_pr.tagging.tag_template (default v{version}).

2. If no valid tag exists, it starts from 0.0.0.

3. It scans commits since that tag (or all commits when no tag exists).

4. It picks a single bump level from Conventional Commit signals:

   Bump	Trigger
   major	BREAKING CHANGE in the body/footer, or ! in the type/scope prefix (e.g. feat!:)
   minor	feat: ...
   patch	fix: ...

5. If no releasable commits are found, the command exits successfully with no changes — a no-op, not an error.

Only the highest applicable bump is used: one breaking change among twenty fixes still means a single major bump.

Previewing the next version

brel next-version runs exactly the same logic and prints the result as plain SemVer:

$ brel next-version
1.3.0

When nothing is releasable it prints nothing and exits 0, so it’s safe to use in scripts and CI conditionals.

What this means for your commits

• Merge commits and non-conventional messages (chore:, docs:, refactor:, or free-form text) never trigger a release on their own.
• The tag template matters: if you change tag_template, existing tags that don’t match the new template are ignored when finding the last release. See Tagging on Merge.