Hey everyone,

I would like to hear people's opinions on using semantic/conventional
commits. I see people occasionally using it, but unless we make it a
"standard" and mandatory (and fail CI if commits are not following
it), IMHO there is virtually no benefit for the whole community.

I am now preparing the June provider's release (a little delayed due
to my unavailability - sorry) and with 60+ providers it's somewhat
manageable without it. I semi-automatically prepare and maintain all
the changelogs now for all providers (I implemented a very simple
heuristics to help with it and classify the commits based on the
commit message) but it requires quite some effort to re-classify the
changes. Not much, it's manageable, but having semantic/conventional
commits would make my (and other release managers) life a bit easier.

For those who are not familiar with - here is the "gist" of it with links:
https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

In short - here are examples of semantic/conventional commit messages:

feat: add hat wobble
fix: fix the hole eaten by moles
doc: describe the hat etiquette
style: make hat follow latest hat conventions
refactor: replace hat underlying construction to be more sturdy
test: test the hat when it's raining
chore: cleanup the hat, it became dusty a bit

Questions:

* What's your experience with using the semantic/conventional commits?
* Do you like/dislike the semantic/conventional commits?
* Should we make them mandatory?
* Maybe there are other ways we can achieve the same results?

J.


-- 
+48 660 796 129

Reply via email to