Codecov Report

All modified and coverable lines are covered by tests ✅

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

@@            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

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

Just opening the debate: wouldn't it be easier and more consistent to fix/align the defaultbump 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 defaultbump 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 thebump --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 specifychangelog_incremental, the Config would store the value asFalse and the value passing intoChangelog should beTrue
2. user did specifychangelog_increamental: true, the Config would store the value asTrue, so the value passing intoChangelog would also beTrue
3. user did specifychangelog_increamental: false, the Config would store the value asFalse, so the value passing intoChangelog would also beFalse

The 1st & 3rd cases would cause ambiguity when we're reading the value fromConfig, 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 ofChangelog. 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 thechangelog_merge_prerelease option, as the argincremental 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.