Description
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).
Activity
woile commentedon Jun 26, 2020
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?
Lee-W commentedon Jun 26, 2020
The basic idea of the dataclass part is to make moving from
dicttodataclasswhich might be clear.The main idea of this issue is to use named capture group to make the regular expression stricter like how you implement
commit_parser.woile commentedon Jun 27, 2020
Oh, I see, the
find_incrementwould have to be completely refactored.Still I see some complications, for conventional commits how would you capture
BREAKING CHANGEand!as breaking chagnes with a named group? I've tried a while ago with little success hahaRegarding 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.
Lee-W commentedon Jun 27, 2020
Things like
(?P<MAJOR>^.*\n\nBREAKING[-]CHANGE.*|)|(?P<MINOR>^feat.*), but not yet testesd.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
woile commentedon Jun 27, 2020
I mean like these cases, how would we parse them? They both introduce breaking changes, and they'd use
MAJORas a group variable, rightLee-W commentedon Jun 28, 2020
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.woile commentedon Apr 28, 2023
Any update on this?
20 remaining items