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 (0b31a73).
⚠️ Report is 6 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #996   +/-   ##
=======================================
  Coverage   97.99%   97.99%           
=======================================
  Files          60       60           
  Lines        2691     2693    +2     
=======================================
+ Hits         2637     2639    +2     
  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),

[josix]

yeah, thanks for pointing it out.

[josix]

weird, seems that it will let tests fail, let me investigate it.

[josix]

Oh, I found the root cause, dict.get only returns the fallback when the key is missing, so .get(..., True) would return None (not True). The explicit check is required to default to incremental changelog generation while still honoring an explicit False.

[Lee-W]

It does remind me that Airflow has an ARG_NOT_SET thing. not sure whether we should have similiar mechanism

[Lee-W]

I think we'll also need more context in this comment. same as the value in default.py. This is probably the best we can do for the time being, but worth thinking of a abetter solution in the following major versions. also would be great if we have a unit test to cover it

[Copilot]

Pull request overview

This PR fixes cz bump --changelog / update_changelog_on_bump = true so that an explicit changelog_incremental = false in user config is respected (i.e., bump-generated changelog is non-incremental when configured).

Changes:

• Change the default changelog_incremental setting to None as a sentinel meaning “not configured by user”.
• Update bump to treat None as “unset” and default to incremental changelog generation during bump, while still honoring explicit true/false.
• Add bump command tests covering unset/true/false changelog_incremental behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
commitizen/defaults.py	Makes changelog_incremental a tri-state setting (`bool
commitizen/commands/bump.py	Uses the tri-state value to default to incremental during bump only when the setting is unset.
tests/test_conf.py	Updates expected default settings to reflect changelog_incremental = None.
tests/commands/test_bump_command.py	Adds regression tests ensuring bump preserves/overwrites manual changelog edits depending on changelog_incremental.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.