ankitects
Consider requiring conventional commit messages
Currently releases take a lot of time, as I need to go through the git commits and figure out new features vs bugfixes, reformat messages, etc. Requiring things like fix/feature/etc tags, and perhaps some consistency of change description, would make the release process simpler.
People who have experience with such schemes on other projects - any thoughts?
Alternatively, we could require changes to a CHANGELOG file on notable user-facing changes?
Not a contributor but happened to stumble across this. Using conventional commits definitely makes it easier to follow what is happening, and they can also allow the auto-generation of releases, changelogs, etc (see, for example folke/lazy.nvim releases)
Also not a contributor, but my experience with this is that it's nice to have the conventional commit-type prefixes fix:, feat:, etc., but if you go overboard with "mandating" much beyond having those and a reasonably clear title, it gets overly tedious and you lose the benefits.
I noticed this discussion and thought it could be helpful to try setting up a workflow for it. I have opened a pull request that adds a GitHub Action to enforce conventional PR titles and updated the README with some short examples: #4363. Hopefully this can be a small step towards making releases easier and the commit history more consistent. Please check it out and let me know what you think!
Thanks all. I had similar thoughts on keeping thing simple: maybe just 'feat' and 'fix', without any category like 'feat(gui):'? Presumably we'd also want a way to exclude PRs from the changelog for non-user-facing changes like dependency updates - could we lump all of those under 'chore:'?
Should we be enforcing this on every commit, or just the PR title? With our current squash merge policy, individual commit tags are not as useful, and requiring only the PR title does reduce friction somewhat. But I can think of arguments for keeping them too: they form the default PR title, they make reviewing PRs easier, and the merge policy may change in the future. Doing it on a per-commit basis also allows us to implement the check in minilints, so users can check their PR is valid prior to pushing it to GitHub*, and avoids us adding a dependency on another GitHub action. Thoughts?
*We'd need to teach it to use a env var to check the actual commit title in CI, as the user may have edited it.
Should we be enforcing this on every commit, or just the PR title?
If we want to enforce it for all commits, I think it's worth adding .pre-commit-config.yaml that runs minilints, so contributors can simply run pre-commit install && pre-commit install to enforce checks locally.
