Proposal: Switch to Conventional Commits

[gerred]

We've been looking at a few ideas and tools around shoring up our commits, making breaking changes more clear, and generally making our release, versioning, and documentation process more automatable.

Introducing: https://www.conventionalcommits.org/en/v1.0.0/

We can use that with tools like commitlint and other Conventional Changelog tooling. We'll still want to write separate notes, but this could help make things a LOT more clear.

I'd like to get the core team's thoughts on this (@alenkacz, @kensipe, @zen-dog especially), and if so, I will PR updating the CONTRIBUTING process and add commitlint as a check and a hook.

Another big benefit, beyond the automation, is it will all help get us into the same mindset with writing good commits.

[alenkacz]

love the idea of improving changelog from commits ❤️ . I see potentially two paths here:

• conventional commits
• something close to what k8s does (have changelog block in PR that is mandatory plus maybe use labels for categorization). Then generate changelog from closed PRs not commits.

The advantage I see in second option is that you can edit PR after it was merged and change labels/changelog message. You cannot do that with commits without force push.

I think I discussed that second option while back with @meichstedt

I am definitely not against conventional commits :)

[gerred]

I do like that second option too! Could we combine these two things, and have that block used for our longer form release notes?

[porridge]

My concern is that this convention requires fixes/refactors and features to be in different commits, but our GitHub configuration only allows squash merges. This means that if I encounter a need to refactor or cleanup something while working on a feature, I'd need to create a separate base PR and wait for it to be merged before even raising the feature PR. I'm afraid that with our 24h delay rule it would either:

1. introduce a lot of latency compared to current situation where both changes could be reviewed in parallel, or
2. discourage applying the boyscout rule (without prejudice to girl scouts)

I can see the following ways around this:

• allow merge commits, or
• raise the latter PR against the branch of the former one, and be careful not to merge it before changing back the target against master

[porridge]

Also, I would expect that a tested way to validate commit correctness on developer workstation is provided before this rule is enforced.