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.

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.

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

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

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.

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?

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.