Should we adopt conventional commits?

[tdcmeehan]

Today, we follow a few conventions which seem slightly esoteric these days:

1. We follow the git commit guidelines from Chris Beams, as documented in our contributing guide.
2. We add tags to the beginning of commits in an ad-hoc way (see: Discussion: When to add tags to Presto git commits? #21342)

Both of these have problems. The guidelines from Chris Beams help to ensure a clean, readable commit history, but they seem difficult to automate or add validation for. For example, it seems like it would be difficult to ensure that the subject line is in the imperative mood. Moreover, it seems because this is all based off of a blog post instead of a real specification, any attempt to validate these commits would have to be a custom tool. Because there is no validation, sometimes PRs are merged with commits which do not conform to our guidelines.

The tags have issues because we are inconsistently applying them (see #21342).

To recap, we like the current way of structuring commits because it ensures a clean, readable commit history, but we would prefer a little more automation and less room for error.

One idea is to use conventional commits. Conventional commits allow us to continue to continue to preserve a readable commit history, but because the format of the commit actually has a specification, we can add validation on the commit message. A quick browse shows that there's many tools that are ready to use off the shelf that support this specification, so we could quickly add validation.

I think if we were to adopt this specification, it would make the PR review easier for everyone--the PR submitter would quickly understand that their commit does not follow the specification (which is widely known and documented outside of Presto), and the PR reviewer would make less mistakes and leave less repetitive feedback. Thoughts?

[imjalpreet]

I’m fully in favor of adopting Conventional Commits.

It keeps the history clean and readable while giving us a well‑defined spec that’s easy to validate. This also means fewer inconsistencies, less repetitive review feedback, and clearer tags like feat: and fix:.

It also aligns us with common open source practices, making it simpler for new contributors.

In addition, I’ve noticed in the past few months that some commits were merged without squashing, introducing unnecessary commits into master. Adopting a spec like this would let us add automated checks to ensure all commits follow the guidelines and avoid such cases.

[aditi-pandit]

+1 to Jalpreets point especially about the squashing of commits.. I've often found it hard to ask folks to reorganize commits in a way that makes sense to deliver into the project code-base.

Adopting conventional commits would ease the review and merge process.