You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But comparing the index is a bit unclear and hard to maintain.
I have implemented it in #1518 a few months ago (but now there are too many conflicts, so I'd prefer to start over and probably split it into several smaller PRs). The function find_increments can be redesigned in a way clearer way:
Extract the subject (first line) of each commit in the git rev range
Map each commit subject to a VersionIncrement, so we have a collection of VersionIncrements
Take the maximum of the collection. (Supposing MAJOR > MINOR > PATCH > NONE)
The implementation of VersionIncrement can be found in #1724.
Replacing the MAJOR/MINOR/PATCH string constants in commitizen/defaults.py and commitizen/bump.py with the existing VersionIncrement IntEnum at commitizen/version_increment.py is a cross-cutting refactor (bump.py, commands/bump.py, commands/version.py, cli.py, plus the entire test suite that compares against literal strings). It's also a breaking change for any external code that imports MAJOR/MINOR/PATCH and compares with ==.
Best done as part of the v5 cleanup so the deprecation doesn't have to span a 4.x release. Surfaced via the round-2 triage in #1965 — proposing this be tracked under #1481 (v5).
Activity
Lee-W commentedon Jan 6, 2026
Why do we need to do it?
bearomorphism commentedon Jan 7, 2026
Commitizen often has to determine which Increment is actually using. For example,
commitizen/commitizen/bump.py
Line 53 in d1f8bf0
But comparing the index is a bit unclear and hard to maintain.
I have implemented it in #1518 a few months ago (but now there are too many conflicts, so I'd prefer to start over and probably split it into several smaller PRs). The function
find_incrementscan be redesigned in a way clearer way:VersionIncrement, so we have a collection ofVersionIncrementsThe implementation of
VersionIncrementcan be found in #1724.bearomorphism commentedon May 9, 2026
Replacing the
MAJOR/MINOR/PATCHstring constants incommitizen/defaults.pyandcommitizen/bump.pywith the existingVersionIncrementIntEnum atcommitizen/version_increment.pyis a cross-cutting refactor (bump.py,commands/bump.py,commands/version.py,cli.py, plus the entire test suite that compares against literal strings). It's also a breaking change for any external code that importsMAJOR/MINOR/PATCHand compares with==.Best done as part of the v5 cleanup so the deprecation doesn't have to span a 4.x release. Surfaced via the round-2 triage in #1965 — proposing this be tracked under #1481 (v5).