|
| 1 | +# Releasing with the SCM Version Provider |
| 2 | + |
| 3 | +## About |
| 4 | + |
| 5 | +When `version_provider` is set to `scm`, Commitizen reads the version directly from your Git tags instead of a config file. |
| 6 | +This provider is **read-only**: it can determine the current version, but it cannot write a new one for you. |
| 7 | + |
| 8 | +```toml title=".cz.toml" |
| 9 | +[tool.commitizen] |
| 10 | +tag_format = "v${version}" |
| 11 | +version_provider = "scm" |
| 12 | +``` |
| 13 | + |
| 14 | +This means `cz bump` cannot complete its usual job of writing the new version anywhere (see [Why can't I bump with SCM?](#why-cant-i-bump-with-scm) below). |
| 15 | + |
| 16 | +## Creating a New Version Tag Manually |
| 17 | + |
| 18 | +To release a new version without an extra commit, compute the next tag yourself and create it directly: |
| 19 | + |
| 20 | +```sh |
| 21 | +next_version=$(cz version --project --next --tag) |
| 22 | +git tag --annotate "$next_version" --message "$next_version" |
| 23 | +git push --follow-tags |
| 24 | +``` |
| 25 | + |
| 26 | +!!! tip |
| 27 | + Wrap this in a CI job to fully automate releases when using the `scm` provider using [setup-cz](github.com/commitizen-tools/setup-cz) |
| 28 | + |
| 29 | +## Why Can't I Bump with SCM? |
| 30 | + |
| 31 | +When you run `cz bump`, Commitizen normally creates a new commit that updates the version somewhere, |
| 32 | +either in `.cz.toml`, or in `pyproject.toml` if you're using Python, or `Cargo.toml` for rust. |
| 33 | +It may also update `version_files` and regenerate `CHANGELOG.md`. |
| 34 | + |
| 35 | +Commitizen deliberately bundles a new release into a single commit. |
| 36 | +This is core to its philosophy: the version should live in the code itself, not only in a Git tag, |
| 37 | +so anyone can read the current version straight from the source, without needing to inspect the tags. |
| 38 | +When a Git tag is the sole source of truth, that guarantee disappears, |
| 39 | +the version becomes metadata layered on top of your history instead of something visible within the code itself. |
| 40 | + |
| 41 | +## Github action example |
| 42 | + |
| 43 | +```yaml title=".github/workflows/bump-version.yml" |
| 44 | +name: Bump version |
| 45 | + |
| 46 | +on: |
| 47 | + push: |
| 48 | + branches: |
| 49 | + - main |
| 50 | + |
| 51 | +jobs: |
| 52 | + bump: |
| 53 | + runs-on: ubuntu-latest |
| 54 | + permissions: |
| 55 | + contents: write |
| 56 | + actions: write |
| 57 | + steps: |
| 58 | + - uses: actions/checkout@v7 |
| 59 | + with: |
| 60 | + token: "${{ secrets.PERSONAL_ACCESS_TOKEN }}" |
| 61 | + fetch-depth: 0 |
| 62 | + fetch-tags: true |
| 63 | + - uses: commitizen-tools/setup-cz@main |
| 64 | + with: |
| 65 | + python-version: "3.x" |
| 66 | + - id: bump-version |
| 67 | + run: | |
| 68 | + next_version=$(cz version --project --next --tag) |
| 69 | + git tag --annotate "$next_version" --message "$next_version" |
| 70 | + git push --follow-tags |
| 71 | +``` |
0 commit comments