Explain "chore:" and "ci:" #163

New Issue

GiteaMirror · 2026-02-17T11:50:35-06:00

GiteaMirror commented

2026-02-17 11:50:35 -06:00

Originally created by @buhtz on GitHub (Dec 28, 2022).

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

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

Originally created by @buhtz on GitHub (Dec 28, 2022). For me it is not clear what `chore:` and `ci:` are meaning. Maybe you can add this information and improve the specification with examples.

GiteaMirror commented

2026-02-17 11:50:36 -06:00

@javier-godoy commented on GitHub (Dec 28, 2022):

Just my two cents.

Only fix and feat are defined by Conventional Commits.

In the summary, it reads:

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.)

@javier-godoy commented on GitHub (Dec 28, 2022): Just my two cents. Only `fix` and `feat` are defined by Conventional Commits. In the summary, it reads: > 4. 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](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type), 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](https://github.com/angular/angular/blob/main/CONTRIBUTING.md) 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](https://github.com/angular/angular/commit/dff6ee32725197bdb81f3f63c5bd9805f2ed22bb#diff-6a3371457528722a734f3c51d9238c13) 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](https://github.com/FlowingCode/DevelopmentConventions/blob/main/conventional-commits.md#1-type) (it's open-sourced, so feel free to use it / adapt it if you find it helpful.)

GiteaMirror commented

2026-02-17 11:50:38 -06:00

@buhtz commented on GitHub (Dec 28, 2022):

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.

@buhtz commented on GitHub (Dec 28, 2022): 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.

GiteaMirror commented

2026-02-17 11:50:39 -06:00

@bcoe commented on GitHub (Jan 30, 2023):

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.

@bcoe commented on GitHub (Jan 30, 2023): 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.

GiteaMirror referenced this issue

2026-02-17 11:59:23 -06:00

[PR #163] [MERGED] feat(lang): Add zh-TW translation for version v1.0.0-beta.4 #331

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#163