Skip to content

Commit 7e01cbc

Browse files
committed
docs(tutorial): add Releasing with the SCM Version Provider
1 parent b7df6e1 commit 7e01cbc

2 files changed

Lines changed: 72 additions & 0 deletions

File tree

docs/tutorials/release-scm.md

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
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+
```

mkdocs.yml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -70,6 +70,7 @@ nav:
7070
- Jenkins pipeline: "tutorials/jenkins_pipeline.md"
7171
- Developmental releases: "tutorials/dev_releases.md"
7272
- Monorepo support: "tutorials/monorepo_guidance.md"
73+
- Release with SCM Version Provider: "tutorials/release-scm.md"
7374
- FAQ: "faq.md"
7475
- "features_wont_add.md"
7576
- Exit Codes: "exit_codes.md"

0 commit comments

Comments
 (0)