Skip to content

Add ability to create changelog on bump by default #290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
janw opened this issue Nov 2, 2020 · 10 comments
Closed

Add ability to create changelog on bump by default #290

janw opened this issue Nov 2, 2020 · 10 comments
Labels
type: feature A new enhacement proposal

Comments

@janw
Copy link
Contributor

janw commented Nov 2, 2020

Description

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

  1. 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.
  2. 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. 👋

@Lee-W
Copy link
Member

Lee-W commented Nov 4, 2020

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.

@Lee-W
Copy link
Member

Lee-W commented Nov 4, 2020

Ah, I missed one detail. I think introducing update_changelog_on_bump to the configuration is great.

@janw
Copy link
Contributor Author

janw commented 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_bump flag so we won't forget including the changelog.

@woile
Copy link
Member

woile commented Nov 4, 2020

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.

@janw
Copy link
Contributor Author

janw commented 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 bump execution would be done manually—unless you have a better idea for such scenarios?

@woile
Copy link
Member

woile commented Nov 4, 2020

unless you have a better idea for such scenarios?

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
Copy link
Member

Lee-W commented 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 the cz bump command a bit more confusing.

@Lee-W
Copy link
Member

Lee-W commented Nov 4, 2020

unless you have a better idea for such scenarios?

I add the command cz bump --changelog to my makefile / tasks.py to solve this problem.

@janw
Copy link
Contributor Author

janw commented Nov 4, 2020

Thank you for both of your input here! I will adjust the (admittedly premature 😬) PR accordingly

@Lee-W
Copy link
Member

Lee-W commented Nov 4, 2020

This issue is closed by #293 . Thanks for your contribution 😃

@Lee-W Lee-W closed this as completed Nov 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature A new enhacement proposal
Projects
None yet
Development

No branches or pull requests

3 participants