Santiago Fraire Willemoes

Not sure how to follow with this one. do we still need it? Would the dataclass be internal or it should be provided for templating?

Oh, I see, the `find_increment` would have to be completely refactored. Still I see some complications, for conventional commits how would you capture `BREAKING CHANGE` and `!` as breaking chagnes...

I mean like these cases, how would we parse them? They both introduce breaking changes, and they'd use `MAJOR` as a group variable, right ``` refactor!: drop support for Python...

For a normal flow it may be too disruptive, you want to move fast by pressing `enter`, I think the multiline should be enabled as a config indeed, set to...

I think ordering by scope wouldn't add much overhead and it would be a nice feature to have

LGTM.Is there an issue associated? What's the problem that it's trying to solve?

I'm haven't use `-S` so I'm not sure I can implement this. Don't you have to create a pair of keys to sign the commits? How would you configure this...

I like this idea. I'm not a user of local-versions per-se, and I'd like to avoid any breaking change for people who are already using it. So I guess as...

Local versions are specified in [pep440#localversions](https://www.python.org/dev/peps/pep-0440/#id25) and if we were to make changes, it should continue to work. Maybe it's not necessary to add them as part of the `tag_format`....

Can you open a new issue @souravjamwal77 ? I think it's unrelated to the original ticket. I think it was introduced here recently: https://github.com/commitizen-tools/commitizen/pull/522#discussion_r905883408