[feature/refactor] Use named capture group in bump_pattern to enable stricter check

Goal make regular expression pattern stricter so that we won’t accidentally match things we don’t need

Description In commitizen/cz/conventional_commits/conventional_commits.py#L33 on command-changelog branch, I use named capture group so that we could use a stricter regular expression like .*\n\nBREAKING CHANGE. The benefit of it is that we don’t have to break the whole commit message into lines like commitizem/bump.py#L31. It can also avoid bump or generate changelog based on commit message like fix --- it does not follow the rule but still match the pattern. Another thought on this topic is that we probably merge the bump_map and bump_pattern into one some data class to store name(e.g., break), pattern(e.g., .*\n\nBREAKING CHANGE), behavior(e.g., PATCH).

[Lee-W]

Still I see some complications, for conventional commits how would you capture BREAKING CHANGE and ! as breaking chagnes with a named group? I’ve tried a while ago with little success haha

Things like (?P<MAJOR>^.*\n\nBREAKING[-]CHANGE.*|)|(?P<MINOR>^feat.*), but not yet testesd.

Regarding the dataclasses I’d need an example to understand it better, for me a dict is usually clearer than anything, and can be easily converted to configuration if it’s kept simple.

I’m working on this refactoring in #203 . (I’ve not yet get to the dataclass part.) IMO, dataclass is a stricter solution and less error-prone. It explicitly indicates the type of each configuration. I’ll give you an example once I implement a prototype

[Lee-W]

It seems we do not need to parse the message when we bump the project version. All we want to know is which version (i.e. MAJOR, MINOR, PATCH) to bump. What we need to know if whether these types (e.g., MAJOR, MINOR, PATCH) of commits exist.