Skip to main content

Bump version

To calculate and set the next semantic version (i.e. bump the version) for the unreleased changes:

git cliff --bump

  • Basic:

    • For example, if you have 1.0.0 and committed "feat: xyz", git-cliff --bump --unreleased will create a changelog for 1.1.0.

  • Tag prefixes:

    • Tag prefixes are also supported, for example testing/v1.0.0-beta.1 can be updated to testing/v1.0.0-beta.2

How it works is that for a semantic versioning such as <MAJOR>.<MINOR>.<PATCH>:

  • "fix:" -> increments PATCH
  • "feat:" -> increments MINOR
  • "scope!" (breaking changes) -> increments MAJOR
note

For unconventional commits, only the subject line (the first line) is used while calculating the next version.

note

The next version is checked against the regex value set by tag_pattern.

Get version​

You can also calculate and print the next semantic version to stdout:

git cliff --bumped-version
tip

You can also get the bumped version from the context as follows:

git cliff --unreleased --bump --context | jq -r .[0].version

Bump to a specific version type​

Optionally, you can specify a bump type in --bump:

git cliff --bump [major|minor|patch]

Zero-based versioning scheme​

When working with a zero-based versioning scheme (i.e., 0.x.y or 0.0.x), it is often desirable to preserve the leading zero even when introducing a breaking change. A switch from 0 to 1 should indicate a higher API stability level.

You can modify the bumping rules to preserve the zero-based versioning scheme in the configuration file.