fix(commands/bump): prevent using incremental changelog when it is set to false in config

[josix]

Fix #883

Description

Since the default behavior of cz bump --changelog is to write incremental changelog, which is different from the default value of changelog_incremental, it is hard to know the value is set from user or the default setting, To address it, I created one more member in BaseConfig to record which property is defined from users so that we could distinguish the value is from default setting or users.

Checklist

• Add test cases to all the changes you introduce
• Run ./scripts/format and ./scripts/test locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

cz bump --changelog should work as false when user configure changelog_incremental to false.

Steps to Test This Pull Request

1. Modify the CHANGELOG file
   

2. Configure pyproject.toml with changelog_incremental = false

3. Run cz bump --changelog

4. Check the CHANGELOG, which the new added content should be replaced
   

Additional context

ditto.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.45%. Comparing base (120d514) to head (d439c38).
Report is 231 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #996      +/-   ##
==========================================
+ Coverage   97.33%   97.45%   +0.11%     
==========================================
  Files          42       55      +13     
  Lines        2104     2398     +294     
==========================================
+ Hits         2048     2337     +289     
- Misses         56       61       +5     

Flag	Coverage Δ
unittests	97.45% <100.00%> (+0.11%)	⬆️

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.

[woile]

Could you add a docstring to this function explaining it a bit further? thanks
Right now it seems it does the same as mutated_settings, but I think the intention is different, right?

[josix]

Yeah, I've added it. Could you help check it, thanks!

[noirbizarre]

Just opening the debate: wouldn't it be easier and more consistent to fix/align the default bump behavior to the default settings (even if this is a breaking change) ?

By adding a fourth settings source of trust (defaults, user settings, cli flags and now mutated settings, fifth if you add the fact that plugins can override some settings), I feel that we are fixing a symptom but making the problem more complex.

[josix]

Just opening the debate: wouldn't it be easier and more consistent to fix/align the default bump behavior to the default settings (even if this is a breaking change) ?

By adding a fourth settings source of trust (defaults, user settings, cli flags and now mutated settings, fifth if you add the fact that plugins can override some settings), I feel that we are fixing a symptom but making the problem more complex.

Yeah, I think that would be a better way to address the issue if possible. The implementation would be easier and also could prevent overriding the behaviors from multiple sources when running the bump --changelog.

[woile]

Just opening the debate: wouldn't it be easier and more consistent to fix/align the default bump behavior to the default settings (even if this is a breaking change) ?

Could you make a proposal for this? It sounds interesting, would be nice if we can simplify the settings

[Lee-W]

I'm a bit confused here. I thought we could solve it by reading the value from config?

[josix]

I thought we could solve it by reading the value from config?

I think there are total three combinations of configurations here:

1. user didn't specify changelog_incremental, the Config would store the value as False and the value passing into Changelog should be True
2. user did specify changelog_increamental: true, the Config would store the value as True, so the value passing into Changelog would also be True
3. user did specify changelog_increamental: false, the Config would store the value as False, so the value passing into Changelog would also be False

The 1st & 3rd cases would cause ambiguity when we're reading the value from Config, we couldn't tell if the False value is set from the default value or user configuration, according to different source of the value we would take different value to pass into the initialization of Changelog. To address this, I introduce one more property that trace the value set from users to help us differentiate them in this PR.

[Lee-W]

we couldn't tell if the False value is set from the default value or user configuration,

I thought the one from the config should overwrite the default. Or did I miss anything?

[Lowaiz]

Hello,

Do you guys have any news on this fix ?
This setting is blocking the changelog_merge_prerelease option, as the arg incremental take the precedence, causing us to split the bump and the changelog generation in order to have proper release changelog with every changes from release-x to release-x+1 concatenated, and not with every intermediate pre-release.