`VersionIncrement` related cleanup

[bearomorphism]

Description

• Replace ['MAJOR', 'MINOR', 'PATCH'] with IntEnums feat(version): add MANUAL_VERSION, --next and --patch to version command #1724
• Remove find_increment

Possible Solution

No response

Additional context

No response

Related issues

No response

[Lee-W]

Replace ['MAJOR', 'MINOR', 'PATCH'] with IntEnums

Why do we need to do it?

[bearomorphism]

Replace ['MAJOR', 'MINOR', 'PATCH'] with IntEnums

Why do we need to do it?

Commitizen often has to determine which Increment is actually using. For example,

commitizen/commitizen/bump.py

Line 53 in d1f8bf0

if VERSION_TYPES.index(increment) < VERSION_TYPES.index(new_increment):

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:

1. Extract the subject (first line) of each commit in the git rev range
2. Map each commit subject to a VersionIncrement, so we have a collection of VersionIncrements
3. Take the maximum of the collection. (Supposing MAJOR > MINOR > PATCH > NONE)

The implementation of VersionIncrement can be found in #1724.

[bearomorphism]

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).