conventional-commits/conventionalcommits.org

Explain "chore:" and "ci:"

buhtz opened this issue · 3 comments

buhtz commented

For me it is not clear what chore: and ci: are meaning.

Maybe you can add this information and improve the specification with examples.

javier-godoy commented

Just my two cents.

Only fix and feat are defined by Conventional Commits.

In the summary, it reads:

  1. types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

Since chore and ci are not defined in Conventional Commits, it's very important that all the committers agree on their meaning.

Regarding chore:, There are several definitions (I ranted about that in FlowingCode/DevelopmentConventions#11).
Which one you choose depends (among other things) on whether you use build and/or ci. The (old) Angular convention, for instance, defined chore as "changes to the build process or auxiliary tools and libraries such as documentation generation") but it lacks specific build and ci types.

The new Angular convention defines build: as "changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)" and ci: as "changes to our CI configuration files and scripts (examples: CircleCi, SauceLabs)". It also removes support for chore: because it was "overused by everyone on the team"

I discussed about it with a colleague (FlowingCode/DevelopmentConventions#10) and we arrived to a slightly different phrasing that makes for sense for us. We summarized it here (it's open-sourced, so feel free to use it / adapt it if you find it helpful.)

  • 👍4
buhtz commented

Thanks for explaining. You should mention in your documents what Angular is. Not all readers know it.
Just use the term "the example project Angular" instead of just "Angular". I first thought it is another specification like conventional commits.

bcoe commented

Just a quick drive by comment, I like @javier-godoy's approach of creating a stricter specification on top of conventional commits. This was my original intention regarding the relationship between the angular convention and the conventional commit convention. Angular's conventions apply to a single project, and therefore it makes sense for them to be more opinionated.

Conventional Commits is not overly opinionated by design.