Configurable version increments per Type #164
Conversation
|
Thank you for the PR. Convco already supports custom types https://github.com/convco/convco/blob/master/src/conventional/commits.rs#L20, but not an increment behavior. I will have a look to your PR later in more details |
src/conventional/config.rs
Outdated
| section: "Fixes".into(), | ||
| hidden: false, | ||
| }, | ||
| Type { | ||
| r#type: "build".into(), | ||
| increment: Increment::Patch, |
There was a problem hiding this comment.
These none fix/feature types should default to the Increment::None. Otherwise this is a breaking change.
There was a problem hiding this comment.
I see what you are saying and will update. Theoretically though, should any new release, even if the interim commits are chore or build or something else minor, not expect at least a patch increment?
There was a problem hiding this comment.
Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).
Unless they contain a breaking change there should not be an implicit effect. If it is configurable it becomes an explicit effect. For example a style: reformatted with new rules should not require a new release imo.
There was a problem hiding this comment.
I see that you are following the spec. But I feel there is a big difference between "should not" and "can not". What if this was a continuous deployment scenario and every merge to main gets released and hence a version number? Regardless, this PR has this covered.
Thanks for taking the time to review my proposal. Do you prefer every commit to be conventional? I was expecting a squash merge and hence the title of the PR would take contain the label. Would you prefer me to reword my commit via rebase? And hence break the history of the PR? |
Indeed I can use the squash and merge. I normally use the rebase and merge as the workflows will make sure a conventional commit is used for each commit. |
… a configurable conventional::config::Increment to each conventional::config::Type
Since the workflows failed I fixed the style issues and squashed the lot down to a single conventional commit. |
|
I fixed the remaining issues here: https://github.com/convco/convco/tree/BRANCH_NAME |
This makes it possible to increment the version for different types then feat and fix. Also replaces conventional type with `String` type instead of enum. Refs: #164
This makes it possible to increment the version for different types then feat and fix. Also replaces conventional type with `String` type instead of enum. Refs: #164
|
Merged with 607c9b1 |
I expect that this PR will be declined as it takes a slightly different view of the ConventionalCommit spec, and actively deviates from the ConventionalChangelog spec, however I would appreciate feedback if possible.
I like convco very much. However, to be of real value to me I need to be able increment either the major, minor or patch via custom types, not constrained to
featandfix. This is allowed by the spec, but not mandated. This PR removesconventional::Typepreferring instead for every type to be aString. It then adds a newIncrementconfig Type field which allows the specification of which value to increment when that type is encountered in the git history.