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.99%. Comparing base (a6db54c) to head (9c8f89a).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #996   +/-   ##
=======================================
  Coverage   97.99%   97.99%           
=======================================
  Files          60       60           
  Lines        2691     2692    +1     
=======================================
+ Hits         2637     2638    +1     
  Misses         54       54           

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

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

[Lee-W]

I probably won't say I love this idea, but it is an acceptable workaround before we introduce a better config system. @josix, could you please rebase it and add some tests to verify it?

[bearomorphism]

@josix what is the status of this PR? Thanks!

[josix]

Oh I missed this comment, let me pick this up

[bearomorphism]

Thanks!

[bearomorphism]

This probably also works and is less confusing

Suggested change

	"incremental": incremental_setting
	if incremental_setting is not None
	else True,
	"incremental": self.config.settings.get("changelog_incremental", True),