[munk-a]

That seems inaccurate, it looks more like fix: feat: are both potentially patch level while fix!: feat!: breaking change: and breaking change!: indicate major changes... possibly? Ouf I think the commit is just absolutely the wrong level to encode this at - I much prefer ticket level encoding of this information.

[JMTQp8lwXL]

I was explaining how standard-version [0] works. Conventional Commits homepage doesn't mention anything about the '!' syntax. [1] I'm unsure if you're suggesting that's how you think it should work, or how it actually works. I haven't ever tried using the '!' syntax, so I can't say for certain.

In terms of release management, it makes configuring CI jobs simpler with one less parameter. If you automatically release merges to master, you can use standard-version with conventional commit syntax. On other projects, I've seen people use GitHub PR labels to mark 'major', 'minor', or 'patch' releases (the CI system reads this information when generating releases).

If you feel it's inappropriate for this information to live in your commit history, you'll need to specify it through one of these other options.

Since I don't have a dedicated team for this sort of infrastructure (I maintain my own Jenkins jobs), I find that Conventional Commits get the job done, so I can focus on other things. There could be better ways, but I have more pressing problems than demand my attention, with higher priority than optimizing my CICD configurations.

[0]: https://github.com/conventional-changelog/standard-version

[1]: https://www.conventionalcommits.org/en/v1.0.0/

[arethuza]

[1] has:

"or appends a ! after the type/scope, introduces a breaking API change"