UAT: `major_version_zero = true` in commitizen config contradicts project version 1.0.0+ #4133

New issue

Open

opened 2026-04-06 10:31:56 +00:00 by freemo · 0 comments

freemo commented

2026-04-06 10:31:56 +00:00

Owner

Metadata

Branch: fix/build/fix-commitizen-major-version-zero
Commit Message: fix(build): set major_version_zero = false in commitizen config to match version 1.0.0+
Milestone: None (backlog)
Parent Epic: #362

Summary

The [tool.commitizen] section in pyproject.toml sets major_version_zero = true, which tells commitizen to treat the project as pre-1.0.0 (i.e., breaking changes bump the minor version, not the major). However, the project is already at version 1.0.0 (per pyproject.toml) and 3.7.0 (per CHANGELOG). Setting major_version_zero = true when the project is past 1.0.0 will cause incorrect version bumping behavior.

Backlog note: This issue was discovered during autonomous UAT testing.
It does not block milestone completion and has been placed in the backlog
for human review and future milestone assignment.

What Was Tested

Read pyproject.toml lines 226–232 ([tool.commitizen])
Read pyproject.toml line 7: version = "1.0.0"
Read CHANGELOG.md line 170: ## [3.7.0] — 2026-04-02

Expected Behavior

Since the project is at version 1.0.0+ (and actually 3.7.0 per CHANGELOG), major_version_zero should be false. With major_version_zero = false, a breaking change (feat!: or BREAKING CHANGE:) will bump the major version (e.g., 3.7.0 → 4.0.0) as expected by semver.

Actual Behavior

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$version"
version_scheme = "pep440"
version_provider = "pep621"
update_changelog_on_bump = true
major_version_zero = true   ← INCORRECT for a 1.0.0+ project

With major_version_zero = true, a breaking change on version 3.7.0 would bump to 3.8.0 instead of 4.0.0, violating semantic versioning.

Steps to Reproduce

grep "major_version_zero" pyproject.toml → major_version_zero = true
grep "^version" pyproject.toml → version = "1.0.0"
grep "## \[" CHANGELOG.md → ## [3.7.0] — 2026-04-02

Code Location

pyproject.toml, line 232

Fix

Change major_version_zero = true to major_version_zero = false:

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$version"
version_scheme = "pep440"
version_provider = "pep621"
update_changelog_on_bump = true
major_version_zero = false   ← CORRECT for 1.0.0+ projects

Subtasks

Change major_version_zero = true to major_version_zero = false in pyproject.toml
Verify cz bump --dry-run produces correct version bumps for feat, fix, and breaking changes

Definition of Done

major_version_zero = false in [tool.commitizen]
Breaking changes correctly bump major version
Associated PR has been merged

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-uat-tester

## Metadata - **Branch**: `fix/build/fix-commitizen-major-version-zero` - **Commit Message**: `fix(build): set major_version_zero = false in commitizen config to match version 1.0.0+` - **Milestone**: None (backlog) - **Parent Epic**: #362 ## Summary The `[tool.commitizen]` section in `pyproject.toml` sets `major_version_zero = true`, which tells commitizen to treat the project as pre-1.0.0 (i.e., breaking changes bump the minor version, not the major). However, the project is already at version `1.0.0` (per `pyproject.toml`) and `3.7.0` (per CHANGELOG). Setting `major_version_zero = true` when the project is past 1.0.0 will cause incorrect version bumping behavior. > **Backlog note:** This issue was discovered during autonomous UAT testing. > It does not block milestone completion and has been placed in the backlog > for human review and future milestone assignment. ## What Was Tested - Read `pyproject.toml` lines 226–232 (`[tool.commitizen]`) - Read `pyproject.toml` line 7: `version = "1.0.0"` - Read `CHANGELOG.md` line 170: `## [3.7.0] — 2026-04-02` ## Expected Behavior Since the project is at version 1.0.0+ (and actually 3.7.0 per CHANGELOG), `major_version_zero` should be `false`. With `major_version_zero = false`, a breaking change (`feat!:` or `BREAKING CHANGE:`) will bump the major version (e.g., 3.7.0 → 4.0.0) as expected by semver. ## Actual Behavior ```toml [tool.commitizen] name = "cz_conventional_commits" tag_format = "$version" version_scheme = "pep440" version_provider = "pep621" update_changelog_on_bump = true major_version_zero = true ← INCORRECT for a 1.0.0+ project ``` With `major_version_zero = true`, a breaking change on version 3.7.0 would bump to 3.8.0 instead of 4.0.0, violating semantic versioning. ## Steps to Reproduce 1. `grep "major_version_zero" pyproject.toml` → `major_version_zero = true` 2. `grep "^version" pyproject.toml` → `version = "1.0.0"` 3. `grep "## \[" CHANGELOG.md` → `## [3.7.0] — 2026-04-02` ## Code Location - `pyproject.toml`, line 232 ## Fix Change `major_version_zero = true` to `major_version_zero = false`: ```toml [tool.commitizen] name = "cz_conventional_commits" tag_format = "$version" version_scheme = "pep440" version_provider = "pep621" update_changelog_on_bump = true major_version_zero = false ← CORRECT for 1.0.0+ projects ``` ## Subtasks - [ ] Change `major_version_zero = true` to `major_version_zero = false` in `pyproject.toml` - [ ] Verify `cz bump --dry-run` produces correct version bumps for feat, fix, and breaking changes ## Definition of Done - [ ] `major_version_zero = false` in `[tool.commitizen]` - [ ] Breaking changes correctly bump major version - [ ] Associated PR has been merged --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-uat-tester

freemo referenced this issue

2026-04-06 10:32:24 +00:00

[Automated] CleverAgents Build Session - 2026-04-06 #3775