Inconsistency in types #15

New Issue

GiteaMirror · 2026-02-17T11:32:16-06:00

GiteaMirror commented

2026-02-17 11:32:16 -06:00

Originally created by @doodlewind on GitHub (Jan 20, 2018).

Two minor confusion points in commit types:

In spec, the type field is specified as a verb, whereas feat itself is a noun, and so does chore, style, perf, etc.
In summary, the types are exampled with colon, e.g.fix:, feat:, while its definition is <type>[optional scope]:, which excludes colon from type name.

Feel free to close this issue if it's too captious 😅

Originally created by @doodlewind on GitHub (Jan 20, 2018). Two minor confusion points in commit types: 1. In [spec](https://conventionalcommits.org/#conventional-commits-specification), the `type` field is specified as a **verb**, whereas `feat` itself is a noun, and so does `chore`, `style`, `perf`, etc. 2. In [summary](https://conventionalcommits.org/#summary), the types are exampled with colon, e.g.`fix:`, `feat:`, while its definition is `<type>[optional scope]:`, which excludes colon from type name. Feel free to close this issue if it's too captious 😅

GiteaMirror closed this issue

2026-02-17 11:32:17 -06:00

GiteaMirror commented

2026-02-17 11:32:18 -06:00

@damianopetrungaro commented on GitHub (Jan 20, 2018):

About the 2 you are not excluding the colon from the type, just moving it at the end of type+scope definition.

About the one i agree, we can also think about the difference between feat and improve, and rename them so that they may be more explicit.

For example in my company we are using conventional commits, and sometimes we have some issue about feat meaning. improve may fit better the case (also another verb but this one is the more generic), because it is not a feature, the are not improving the performance, we are not refactoring but we are improving the implementation of the functionality.

@damianopetrungaro commented on GitHub (Jan 20, 2018): About the 2 you are not excluding the colon from the type, just moving it at the end of type+scope definition. About the one i agree, we can also think about the difference between `feat` and `improve`, and rename them so that they may be more explicit. For example in my company we are using conventional commits, and sometimes we have some issue about `feat` meaning. `improve` may fit better the case (also another verb but this one is the more generic), because it is not a feature, the are not improving the performance, we are not refactoring but we are improving the implementation of the functionality.

GiteaMirror commented

2026-02-17 11:32:19 -06:00

@damianopetrungaro commented on GitHub (Jan 20, 2018):

I think it's related also to #28. We can change in a more explicit and clear way.

@damianopetrungaro commented on GitHub (Jan 20, 2018): I think it's related also to #28. We can change in a more explicit and clear way.

GiteaMirror commented

2026-02-17 11:32:20 -06:00

@stevemao commented on GitHub (Jan 22, 2018):

In spec, the type field is specified as a verb, whereas feat itself is a noun, and so does chore, style, perf, etc.

It's definitely a noun not a verb. PR welcome.

In summary, the types are exampled with colon, e.g.fix:, feat:, while its definition is [optional scope]:, which excludes colon from type name.

I don't really understand this and it seems correct to me. Maybe @damianopetrungaro got the point.

@stevemao commented on GitHub (Jan 22, 2018): > In spec, the type field is specified as a verb, whereas feat itself is a noun, and so does chore, style, perf, etc. It's definitely a noun not a verb. PR welcome. > In summary, the types are exampled with colon, e.g.fix:, feat:, while its definition is <type>[optional scope]:, which excludes colon from type name. I don't really understand this and it seems correct to me. Maybe @damianopetrungaro got the point.

GiteaMirror commented

2026-02-17 11:32:21 -06:00

@doodlewind commented on GitHub (Jan 22, 2018):

@stevemao the formal definition is <type>[optional scope]:, so I guess feat is a valid type while feat: may not? See also json spec, its pair consists of string : value, so in a captious way, string is valid instead of string:.

@doodlewind commented on GitHub (Jan 22, 2018): @stevemao the formal definition is `<type>[optional scope]:`, so I guess `feat` is a valid type while `feat:` may not? See also [json spec](http://json.org/), its `pair` consists of `string : value`, so in a captious way, `string` is valid instead of `string:`.

GiteaMirror commented

2026-02-17 11:32:22 -06:00

@stevemao commented on GitHub (Jan 22, 2018):

feat is a type, : is just a separator. when the scope is omitted, it looks like feat: short description. Its the same as feat(): short description or feat(*): short description

@stevemao commented on GitHub (Jan 22, 2018): `feat` is a type, `:` is just a separator. when the `scope` is omitted, it looks like `feat: short description`. Its the same as `feat(): short description` or `feat(*): short description`

GiteaMirror commented

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

@stevemao commented on GitHub (Jan 22, 2018):

I've seen all three forms in the angular project. Maybe we should recommend one of them? cc @bcoe

@stevemao commented on GitHub (Jan 22, 2018): I've seen all three forms in the angular project. Maybe we should recommend one of them? cc @bcoe

GiteaMirror commented

2026-02-17 11:32:24 -06:00

@damianopetrungaro commented on GitHub (Jan 22, 2018):

@stevemao and @doodlewind wdyt about split feat in improve and another verb for add a feature (@doodlewind any suggestion?)

So that we have both the use cases separated and well defined?

@damianopetrungaro commented on GitHub (Jan 22, 2018): @stevemao and @doodlewind wdyt about split `feat` in `improve` and another verb for `add a feature` (@doodlewind any suggestion?) So that we have both the use cases separated and well defined?

GiteaMirror commented

2026-02-17 11:32:26 -06:00

@stevemao commented on GitHub (Jan 22, 2018):

@damianopetrungaro I'm open to suggestions on that. The angular convention was designed for non monorepos and feat was just meant to be for end users. In a monorepo this could be confusing.

@stevemao commented on GitHub (Jan 22, 2018): @damianopetrungaro I'm open to suggestions on that. The angular convention was designed for non monorepos and `feat` was just meant to be for end users. In a monorepo this could be confusing.

GiteaMirror referenced this issue

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

[PR #15] [CLOSED] feat(specs): rewrite spec of syntax #243

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#15