|`MINOR`| New features|`feat`|

|`PATCH`| Fixes and improvements|`fix`,`perf`,`refactor`|

By default, Commitizen uses[PEP 440][pep440] for version formatting. You can switch to semantic versioning using either:

-`pep440`:[PEP 440][pep440] (**default** and recommended for Python projects)

-`semver`:[Semantic Versioning][semver] (recommended for non-Python projects)

You can also set this in the[configuration](#version_scheme) with`version_scheme = "semver"`.

You can also set this in the configuration file with`version_scheme = "semver"`.

!!! note

[pep440][pep440] and[semver][semver] are quite similar, although their difference lies in

Bumps the version in the files defined in[`version_files`](#version_files) without creating a commit and tag on the git repository.

Bumps the version in the files defined in[`version_files`][version_files] without creating a commit and tag on the git repository.

cz bump --files-only

Check whether the versions defined in[`version_files`](#version_files) and the version in Commitizen configuration are consistent before bumping version.

Check whether the versions defined in[version_files][version_files] and the version in Commitizen configuration are consistent before bumping version.

cz bump --check-consistency

setup(...,version="1.0.5",...)

When you run`cz bump --check-consistency`, Commitizen will verify that the current version in`pyproject.toml` (`1.21.0`) exists in all files listed in[`version_files`](#version_files).

When you run`cz bump --check-consistency`, Commitizen will verify that the current version in`pyproject.toml` (`1.21.0`) exists in all files listed in[version_files][version_files].

In this example, it will detect that`setup.py` contains`1.0.5` instead of`1.21.0`, causing the bump to fail.

!!! warning "Partial updates on failure"

annotated_tag =true

!!! note

By default, Commitizen uses lightweight tags.

Create annotated tags with the given message.

cz bump --gpg-sign

!!! note

By default, Commitizen uses lightweight tags.

Provides your own changelog jinja template.

See[the template customization section](../customization.md#customizing-the-changelog-template)

See[the template customization section](../customization/changelog_template.md)

cz bump --changelog --extra key=value -e short="quoted value"

See[the template customization section](../customization.md#customizing-the-changelog-template).

See[the template customization section](../customization/changelog_template.md).

See[Version Schemes](#version-schemes-version-scheme).

`tag_format` and[`version_scheme`](#version-schemes-version-scheme) are combined to make Git tag names from versions.

`tag_format` and[version_scheme][version_scheme] are combined to make Git tag names from versions.

These are used in:

|`$prerelease`,`${prerelease}`| Prerelease (alpha, beta, release candidate)|

|`$devrelease`,`${devrelease}`| Development release|

Identify the files or glob patterns which should be updated with the new version.

Commitizen will update its configuration file automatically when bumping,

regardless of whether the file is present or not in`version_files`.

You may specify the`version_files` in your configuration file.

```toml title="pyproject.toml"

[tool.commitizen]

version_files = [

"src/__version__.py",

]

It is also possible to provide a pattern for each file, separated by a colon (e.g.`file:pattern`). See the below example for more details.

```toml title="pyproject.toml"

[tool.commitizen]

version_files = [

"packages/*/pyproject.toml:version",

"setup.json:version",

]

We have a project with the following configuration file`pyproject.toml`:

```toml title="pyproject.toml"

[tool.commitizen]

version_files = [

"src/__version__.py",

"packages/*/pyproject.toml:version",

"setup.json:version",

]

For the reference`"setup.json:version"`, it means that it will look for a file`setup.json` and will only change the lines that contain the substring`"version"`.

For example, if the content of`setup.json` is:

```json title="setup.json"

{

"name":"magictool",

"version":"1.2.3",

"dependencies": {

"lodash":"1.2.3"

}

}

After running`cz bump 2.0.0`, its content will be updated to:

```diff title="setup.json"

{

"name": "magictool",

"dependencies": {

"lodash": "1.2.3"

}

}

!!! note

Files can be specified using relative (to the execution) paths, absolute paths, or glob patterns.

!!! note "Historical note"

This option was renamed from`files` to`version_files`.

Template used to specify the commit message generated when bumping.

Defaults to:`bump: version $current_version → $new_version`

| Variable| Description|

| ------------------| -----------------------------------|

|`$current_version`| the version existing before bumping|

|`$new_version`| version generated after bumping|

```toml title="pyproject.toml"

[tool.commitizen]

bump_message ="release $current_version → $new_version [skip-ci]"

When set to`true`,`cz bump` is equivalent to`cz bump --changelog`.

```toml title="pyproject.toml"

[tool.commitizen]

update_changelog_on_bump =true

When set to`true`,`cz bump` is equivalent to`cz bump --annotated-tag`.

```toml title="pyproject.toml"

[tool.commitizen]

annotated_tag =true

When set to`true`,`cz bump` is equivalent to`cz bump --gpg-sign`. See[--gpg-sign](#-gpg-sign).

```toml title="pyproject.toml"

[tool.commitizen]

gpg_sign =true

When set to`true`,`cz bump` is equivalent to`cz bump --major-version-zero`. See[--major-version-zero](#-major-version-zero).

```toml title="pyproject.toml"

[tool.commitizen]

major_version_zero =true

A list of optional commands that will run right_after_ updating[`version_files`](#version_files)

and_before_ actual committing and tagging the release.

Useful when you need to generate documentation based on the new version. During

execution of the script, some environment variables are available:

| Variable| Description|

| ----------------------------| ----------------------------------------------------------|

|`CZ_PRE_IS_INITIAL`|`True` when this is the initial release,`False` otherwise|

|`CZ_PRE_CURRENT_VERSION`| Current version, before the bump|

|`CZ_PRE_CURRENT_TAG_VERSION`| Current version tag, before the bump|

|`CZ_PRE_NEW_VERSION`| New version, after the bump|

|`CZ_PRE_NEW_TAG_VERSION`| New version tag, after the bump|

|`CZ_PRE_MESSAGE`| Commit message of the bump|

|`CZ_PRE_INCREMENT`| Whether this is a`MAJOR`,`MINOR` or`PATCH` release|

|`CZ_PRE_CHANGELOG_FILE_NAME`| Path to the changelog file, if available|

```toml title="pyproject.toml"

[tool.commitizen]

pre_bump_hooks = [

]

A list of optional commands that will run right_after_ committing and tagging the release.

Useful when you need to send notifications about a release, or further automate deploying the

release. During execution of the script, some environment variables are available:

| Variable| Description|

| ------------------------------| -----------------------------------------------------------|

|`CZ_POST_WAS_INITIAL`|`True` when this was the initial release,`False` otherwise|

|`CZ_POST_PREVIOUS_VERSION`| Previous version, before the bump|

|`CZ_POST_PREVIOUS_TAG_VERSION`| Previous version tag, before the bump|

|`CZ_POST_CURRENT_VERSION`| Current version, after the bump|

|`CZ_POST_CURRENT_TAG_VERSION`| Current version tag, after the bump|

|`CZ_POST_MESSAGE`| Commit message of the bump|

|`CZ_POST_INCREMENT`| Whether this was a`MAJOR`,`MINOR` or`PATCH` release|

|`CZ_POST_CHANGELOG_FILE_NAME`| Path to the changelog file, if available|

```toml title="pyproject.toml"

[tool.commitizen]

post_bump_hooks = [

]

Offset with which to start counting prereleases.

Defaults to:`0`

```toml title="pyproject.toml"

[tool.commitizen]

prerelease_offset =1

See[Version Schemes](#version-schemes-version-scheme).

Some situations from Commitizen raise an exit code different from 0.

cz -nr 21 bump

Read the[customizing section](../customization.md).

[pep440]:https://www.python.org/dev/peps/pep-0440/

[semver]:https://semver.org/

[version_files]:../config/bump.md#version_files