feat(version-schemes): add monotonic version scheme implementation

[YazdanRa]

Description

Added a new version scheme for monotonic single number versions. e.g. v1 -> v2 -> v3 -> ...

Checklist

• [X] I have read the contributing guidelines

Code Changes

• [X] Add test cases to all the changes you introduce
• [X] Run poetry all locally to ensure this change passes linter check and tests
• [X] Manually test the changes:
  • [X] Verify the feature/bug fix works as expected in real-world scenarios
  • [X] Test edge cases and error conditions
  • [X] Ensure backward compatibility is maintained
  • [ ] Document any manual testing steps performed
• [ ] Update the documentation for the changes

Documentation Changes

• [ ] Run poetry doc locally to ensure the documentation pages renders correctly
• [ ] Check and fix any broken links (internal or external) in the documentation

Expected Behavior

In some scenarios, we have to use a single number as our version that increases as code progress. For these kind of verions that doesn't follow a 3 part section, I introduced a new version_scheme called monotonic which increases the version by 1 in any situation. Furthermore, we can generate changelog for repos with monotonic tags.

Steps to Test This Pull Request

1. Running new unit tests.
2. Install the new artifact via pip install https://github.com/YazdanRa/commitizen/releases/download/v4.10.0b1/commitizen-4.10.0.tar.gz.
3. Update the pyproject.toml file with version_scheme = "monotonic" or use the --version-scheme=monotinic param.

Additional Context

#1704 I have added this feature for our own use, in some scenarios we have to use a monotonic version to be in sync with our registry.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :warning: Please upload report for BASE (v4-11-0@2072f8e). Learn more about missing BASE report.

Additional details and impacted files

@@            Coverage Diff             @@
##             v4-11-0    #1705   +/-   ##
==========================================
  Coverage           ?   97.84%           
==========================================
  Files              ?       60           
  Lines              ?     2604           
  Branches           ?        0           
==========================================
  Hits               ?     2548           
  Misses             ?       56           
  Partials           ?        0           

Flag	Coverage Δ
unittests	97.84% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bearomorphism]

As I mentioned in #1704, please publish the new version scheme as a third-party plugin.

You may either reuse this branch or create another branch to update the third-party plugin list. Thanks!

[YazdanRa]

What should it be?

[bearomorphism]

@Lee-W wdyt

[YazdanRa]

Please let me know if any action is needed on my end ツ

[Lee-W]

@woile based on our design, I think 1.2 is essentially 1.2.0. Do you think there would be exception that these 2 are different?

[YazdanRa]

Will send another PR to add the plugin documentation after the next release.

Thanks and happy holidays!

[woile]

@Lee-W I usually understand 1.2 as the full range of versions: 1.2.0, 1.2.1, 1.2.3... etc. This in something like npm.

In the case that we are not talking about semver, the semantics could change and what we know would no longer apply. It would depend on how the version scheme is designed. For example, python itself doesn't use semver nor pep440. A bump like 3.12 to 3.13 introduces breaking changes, and even though they have patches, what people use is the major.minor to reference a version

[noirbizarre]

Agreed with @Lee-W it needs documentation to be merged.

To me it also need more testing as I agree with @woile, to me 1.2 is the latest 1.2.x.

I fear this can have unexpected effects on repository maintaining Docker-like or github actions like tagging (which is my case on some repository):

• latest version is tagged x.y.z
• an action will automatically move the rolling tags x.y and x to match

So in the case of a bump 1.2.3 from to 1.2.4, there will be a 1.2 and 1 tag on the same commit.

This case is relatively common and need to be tested (to avoid errors like duplicate tags).