You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add ability to create changelog on bump by default #290
I'd love for commitizen to configurable to have the --changelog flag set by default on bump. This would reduce friction in adopting commitizen by avoiding a missing updated changelog on version bumps.
Possible Solution
Introduce a configuration flag à la update_changelog_on_bump (defaulting to False to mimic current behavior), that when set to True would have the same effect as providing the --changelog flag.
Introduce a negated version for --changelog (e.g. --no-changelog) to disable changelog generation for one version bump.
If this is something the maintainers agree is a useful feature, I'd be happy to implement it and provide a PR for it. 👋
Hi, thanks for the suggestion. However, I'm a bit against this idea. I think when a user enters cz bump what they expect is bumping instead of bumping and generating the changelog at the same time.
Yes, I'm not suggesting to always create a changelog but to keep the current default in place (no changelog) but to give an option to do it.
I'm working on a project where our release cycle should contain a single commit for changelog update and version bumping. That's where I'd want to set that update_changelog_on_bump flag so we won't forget including the changelog.
I'm not very fond of this change, cz bump is clear enough on what work it does, if it's also creating the changelog it may generate confusion, it's less readable. Doing cz bump -c or cz bump --changelog can only be forgotten if manually done.
You are absolutely right, the ultimate goal should be to automate this step entirely in CI. Unfortunately, while adopting commitizen to a long-running project with a considerable amount of established processes it is not (immediately) feasible to automate this. Furthermore it might not be desired by all projects to bump versions every time when feat/fix commits are merged to the main branch. I can imagine a case in which a minor release is only created after multiple non-breaking feature merges for example. And in that case the bump execution would be done manually—unless you have a better idea for such scenarios?
@woile I think the users are supposed to know what they're doing when they add a new configuration. Thus, I'm okay with the idea of update_changelog_on_bump. But I'm not into the idea of --no-changelog. It will make the cz bump command a bit more confusing.
Activity
Lee-W commentedon Nov 4, 2020
Hi, thanks for the suggestion. However, I'm a bit against this idea. I think when a user enters
cz bumpwhat they expect is bumping instead of bumping and generating the changelog at the same time.Lee-W commentedon Nov 4, 2020
Ah, I missed one detail. I think introducing
update_changelog_on_bumpto the configuration is great.janw commentedon Nov 4, 2020
Yes, I'm not suggesting to always create a changelog but to keep the current default in place (no changelog) but to give an option to do it.
I'm working on a project where our release cycle should contain a single commit for changelog update and version bumping. That's where I'd want to set that
update_changelog_on_bumpflag so we won't forget including the changelog.woile commentedon Nov 4, 2020
I'm not very fond of this change,
cz bumpis clear enough on what work it does, if it's also creating the changelog it may generate confusion, it's less readable. Doingcz bump -corcz bump --changelogcan only be forgotten if manually done.janw commentedon Nov 4, 2020
You are absolutely right, the ultimate goal should be to automate this step entirely in CI. Unfortunately, while adopting commitizen to a long-running project with a considerable amount of established processes it is not (immediately) feasible to automate this. Furthermore it might not be desired by all projects to bump versions every time when feat/fix commits are merged to the main branch. I can imagine a case in which a minor release is only created after multiple non-breaking feature merges for example. And in that case the
bumpexecution would be done manually—unless you have a better idea for such scenarios?woile commentedon Nov 4, 2020
Most CI's have a manual trigger. Here's an example of github actions, Jenkins and gitlab-ci also support prompts or "buttons".
I'm not sure, I totally think it makes a job less readable, but on the other hand if it helps adoption. I'll let @Lee-W decide.
Lee-W commentedon Nov 4, 2020
@woile I think the users are supposed to know what they're doing when they add a new configuration. Thus, I'm okay with the idea of
update_changelog_on_bump. But I'm not into the idea of--no-changelog. It will make thecz bumpcommand a bit more confusing.Lee-W commentedon Nov 4, 2020
I add the command
cz bump --changelogto mymakefile/tasks.pyto solve this problem.janw commentedon Nov 4, 2020
Thank you for both of your input here! I will adjust the (admittedly premature 😬) PR accordingly
Lee-W commentedon Nov 4, 2020
This issue is closed by #293 . Thanks for your contribution 😃