feat(release): make the bump version rules configurable

[jsurkont]

closes #447

Description

This change adds a customization for version bumping. Specifically, it allows changing the default version bumping rules in order to preserve zero-based releases.

Motivation and Context

The current bumping rules are hard-coded, so it's necessary to extend the input arguments to allow for customization.

This PR adds a new CLI flag --keep-zerover. I also considered extending the configuration. However, it wasn't clear to me which section would be appropriate. Perhaps changelog? I think that having it in the configuration would be quite convenient to users. It would also mean that the signature of Changelog::bump_version doesn't need to be modified. What do you think?

This PR closes #447.

How Has This Been Tested?

I extended the unit tests for calculate_next_version. I also run git cliff with and without the new flag.

Screenshots / Logs (if applicable)

Types of Changes

I wasn't sure if this should be considered a breaking change, but I've marked is a such to be on the safe side. My guess is that there wouldn't be a large number (if any) of users who use the current bump version feature with zero-based releases, as it would result in moving away from the zero-based system.

• Bug fix (non-breaking change which fixesan issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.

[welcome]

Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 41.23%. Comparing base (830528c) to head (47bd294).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #530      +/-   ##
==========================================
+ Coverage   40.94%   41.23%   +0.29%     
==========================================
  Files          15       15              
  Lines        1043     1048       +5     
==========================================
+ Hits          427      432       +5     
  Misses        616      616              

Flag	Coverage Δ
unit-tests	41.23% <100.00%> (+0.29%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[orhun]

I'm thinking if we should offer this as a config option (also environment variable) rather than a command-line argument. I don't think this will be used very often especially when the user is only interested in changelog generation rather than bumping the version. What do you think?

[jsurkont]

I agree. I guess that, for the majority of projects, adding this option to the configuration (or using an environmental variable) would be the most convenient way.

Do you have a preference under which config section this option should be added?

[orhun]

I think the best option would be to add a new section as follows:

[bump]
# Configures automatic minor version increments for feature changes.
# When true, a feature will always trigger a minor version update.
# When false, a feature will trigger:
# - a patch version update if the major version is 0.
# - a minor version update otherwise.
features_always_bump_minor = true
# Configures 0 -> 1 major version increments for breaking changes.
# When true, a breaking change commit will always trigger a major version update
# (including the transition from version 0 to 1)
# When false, a breaking change commit will trigger:
# - a minor version update if the major version is 0.
# - a major version update otherwise.
breaking_always_bump_major = true

What do you think?

[jsurkont]

Yes, I think this is the cleanest solution ✨

I've just updated my PR to use the new config section. I also changed the code so it doesn't change the pubic api of git-cliff-core at a (small) cost of function repetition. Unfortunately, the "Semver" check is still failing because of adding a new field to the Config struct.

[orhun]

Looks good! Can you also add a test fixture? There is also one example under test-bump-version.

[orhun]

Awesome, thanks for your contribution!

[welcome]

Congrats on merging your first pull request! ⛰️