feat: conventional commits

[melekes]

Check PR title follows the Conventional Commits spec.

---

PR checklist

• Tests written/updated
• Changelog entry added in .changelog (we use unclog to manage our changelog)
• Updated relevant documentation (docs/ or spec/) and code comments

[mzabaluev]

As this PR suggests adding and enforcing another discipline to our workflow that is bound to add some overhead, let's not skip the usual requirements we have for PRs. I'd like to have these points discussed:

• What are the improvements and problems that this convention addresses?
• Does this overlap with our existing .changelog process of recording changes?
• If this is going to be some "source of truth" for analyzing change history, are there ways to make corrections that do not involve force-pushing to e.g. main?

[sergio-mena]

@mzabaluev makes sense. Can we add it to next Monday's agenda?
@melekes can we hold on merging this PR until the discussion takes place?

[mzabaluev]

As discussed in earlier comments, let's go through the suggested process changes as a team first.

[faddat]

I think this is a really good idea.

I'm not really a fan of unclog.

[melekes]

@melekes can we hold on merging this PR until the discussion takes place?

sure 👌

[melekes]

What are the improvements and problems that this convention addresses?

Lack of structure in commits that land on the main branch.

Does this overlap with our existing .changelog process of recording changes?

Short answer: no. Long answer: we could replace unclog with something like https://github.com/conventional-changelog/conventional-changelog if we want in the future, which generates a changelog from the Git history. But this is not why I created this PR.

If this is going to be some "source of truth" for analyzing change history, are there ways to make corrections that do not involve force-pushing to e.g. main?

Do you mean that you can always edit the unclog entry prior to release but can't edit the commit message in the main branch? This would be one reason not to use https://github.com/conventional-changelog/conventional-changelog and continue using unclog then. But again, the intention behind this PR is not to replace unclog.

[thanethomson]

For context, the whole reason why I created unclog was to deliberately separate the Git commit log (which targets developers) from the changelog (which targets users). And also to avoid the annoying and unnecessary conflicts created by multiple PRs attempting to update the CHANGELOG_PENDING.md file (the old process).

We considered conventional commits as a standard previously, but this suffers from the problems that @mzabaluev has outlined here and assumes that we only have one target audience for the changelog and commits (which is not true).

I do, however, think that conventional commits as a standard for clean commit messages is great, as long as those commit messages are not used to auto-generate changelogs.

[adizere]

Let's write down the categories, then LGTM

resolved