10 ms·

> feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone

> feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone. fix: <-- patch feat: <-- minor breaking: <-- major

munk-a 7y ago
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 7y ago
  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 https://github.com/conventional-changelog/standard-version [1]: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
  - arethuza 7y ago
    [1] has: "or appends a ! after the type/scope, introduces a breaking API change"
bluejekyll 7y ago
So why not just use patch, minor, major? Then we don’t even need the indirection. Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.
- boudin 7y ago
  In this case you suppose to add a ! after fix: fix! By using patch, minor and major you lose some information (the purpose of the commit)
Vinnl 7y ago
I've got an "Unreleased" section in my changelog in which I log any changes that are relevant to consumers, with sections for bug fixes, new features, and breaking changes. No need to clutter my commits with that.

munk-a 7y ago

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 7y ago
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 https://github.com/conventional-changelog/standard-version [1]: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
- arethuza 7y ago
  [1] has: "or appends a ! after the type/scope, introduces a breaking API change"

bluejekyll 7y ago

So why not just use patch, minor, major? Then we don’t even need the indirection. Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.

boudin 7y ago
In this case you suppose to add a ! after fix: fix! By using patch, minor and major you lose some information (the purpose of the commit)

Vinnl 7y ago

I've got an "Unreleased" section in my changelog in which I log any changes that are relevant to consumers, with sections for bug fixes, new features, and breaking changes. No need to clutter my commits with that.