About the meanings of "feat" #13

New Issue

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

GiteaMirror commented

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

Originally created by @AoDev on GitHub (Dec 5, 2017).

Hello, I am not sure it's the right repo for this. If it is not, please let me know.
I wish to understand better the semantics of "feat".

Regarding the "feat" keyword. I have trouble with it depending on the perspective.

feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).

There are two points of view: the product perspective vs development perspective.

Let's say a dev introduces a new cool reusable UI component.

From a dev point of view, this could be a new feature.
feat(UI): add super new generic graph visualizer
But from product point of view, it is nothing, we haven't given anything new to our app consumers.

Then later, this component is used to display some data.

From a dev point of view, this is again a feature.
feat(reports): display reports graph for x
From product point of view, it is an actual new feature being released.

Now, for a generated changelog, it's a bit of a problem because we are mixing "developer features" with "product features" and releases are unclear or with unnecessary information for people only interested in the "product features".

I was wondering how people make this difference and maybe clarify the semantics on conventionalcommits.org :)

Originally created by @AoDev on GitHub (Dec 5, 2017). Hello, I am not sure it's the right repo for this. If it is not, please let me know. I wish to understand better the semantics of "feat". Regarding the "feat" keyword. I have trouble with it depending on the perspective. > feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning). There are two points of view: the _product perspective_ vs _development perspective_. Let's say a dev introduces a new cool reusable UI component. - From a dev point of view, this could be a new feature. `feat(UI): add super new generic graph visualizer` - But from product point of view, it is nothing, we haven't given anything new to our app consumers. Then later, this component is used to display some data. - From a dev point of view, this is again a feature. `feat(reports): display reports graph for x` - From product point of view, it is an actual new feature being released. Now, for a generated changelog, it's a bit of a problem because we are mixing "developer features" with "product features" and releases are unclear or with unnecessary information for people only interested in the "product features". I was wondering how people make this difference and maybe clarify the semantics on conventionalcommits.org :)

GiteaMirror closed this issue

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

GiteaMirror commented

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

@stevemao commented on GitHub (Dec 6, 2017):

I think feat should be a new feature to your end-user. So if your product is for a business, it'd be a business feature. If your product is a tool, then a feat is a new feature in your tool, which helps to improve the dev experience of your end-user, developers.

This is also why we don't include things like docs, ci or chore in the changelog, because they have very little to do with your end-users.

From a dev point of view, this could be a new feature.
feat(UI): add super new generic graph visualizer

You might wanna consider build, ci or chore.

@stevemao commented on GitHub (Dec 6, 2017): I think `feat` should be a new feature to your end-user. So if your product is for a business, it'd be a business feature. If your product is a tool, then a `feat` is a new feature in your tool, which helps to improve the dev experience of your end-user, developers. This is also why we don't include things like `docs`, `ci` or `chore` in the changelog, because they have very little to do with your end-users. > From a dev point of view, this could be a new feature. feat(UI): add super new generic graph visualizer You might wanna consider `build`, `ci` or `chore`.

GiteaMirror commented

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

@AoDev commented on GitHub (Dec 6, 2017):

I am not too sure about using build, ci or chore for "unexposed /dev features". But, if feat is meant to be for product level only, then should we reflect this in the definition?

feat: a commit of the type feat introduces a new feature ~~to the codebase~~ for the end-users of your product / library (this correlates with MINOR in semantic versioning).

edit: Look at this angular commit for example:
It does not look as a user facing feature but still it's a "feat". 2e03aedc85

feat($parse): add a hidden interface to retrieve an expression's AST
This PR adds a new private method to the $parse service, $$getAst,
which takes an Angular expression as its only argument and returns
the computed AST. This feature is not meant to be part of the public
API and might be subject to changes, so use it with caution.

@AoDev commented on GitHub (Dec 6, 2017): I am not too sure about using build, ci or chore for "unexposed /dev features". But, if feat is meant to be for product level only, then should we reflect this in the definition? feat: a commit of the type feat introduces a new feature ~to the codebase~ __for the end-users of your product / library__ (this correlates with MINOR in semantic versioning). edit: Look at this angular commit for example: It does not look as a user facing feature but still it's a "feat". https://github.com/angular/angular.js/commit/2e03aedc8520bb863e465b0f35030a02ebe2cade > feat($parse): add a hidden interface to retrieve an expression's AST This PR adds a new private method to the `$parse` service, `$$getAst`, which takes an Angular expression as its only argument and returns the computed AST. This feature is not meant to be part of the public API and might be subject to changes, so use it with caution.

GiteaMirror commented

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

@stevemao commented on GitHub (Dec 6, 2017):

It is, indeed, a bit ambiguous about what feat actually means.

feat: a commit of the type feat introduces a new feature to the codebase for the end-users of your product / library (this correlates with MINOR in semantic versioning).

I agree. And I believe this was the original purpose too. Even with the angular team they are not writing the perfect commit messages.

@stevemao commented on GitHub (Dec 6, 2017): It is, indeed, a bit ambiguous about what `feat` actually means. > feat: a commit of the type feat introduces a new feature to the codebase for the end-users of your product / library (this correlates with MINOR in semantic versioning). I agree. And I believe this was the original purpose too. Even with the angular team they are not writing the perfect commit messages.

GiteaMirror commented

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

@AoDev commented on GitHub (Dec 8, 2017):

@stevemao How should we proceed? I think it would be nice to update the meaning on the website.

In practice what I am doing right now in my repos is:

feat is both "internal dev feature" and "product feature"
changelog is created with standard-version
changelog has both product and dev features.
github release (connected to zappier for product people) gets an edited version of the changelog.

Possibly, I am thinking to introduce a type "internal feature for dev" to stay compliant with the original purpose. This is useful because shared modules / helpers are often in the same codebase but dev are not always aware they got a new tool to use and might reinvent the wheel.

@AoDev commented on GitHub (Dec 8, 2017): @stevemao How should we proceed? I think it would be nice to update the meaning on the website. In practice what I am doing right now in my repos is: - feat is both "internal dev feature" and "product feature" - changelog is created with standard-version - changelog has both product and dev features. - github release (connected to zappier for product people) gets an edited version of the changelog. Possibly, I am thinking to introduce a _type_ "internal feature for dev" to stay compliant with the original purpose. This is useful because shared modules / helpers are often in the same codebase but dev are not always aware they got a new tool to use and might reinvent the wheel.

GiteaMirror commented

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

@about-code commented on GitHub (Jan 13, 2018):

I would prefer to see something like enhance to classify enhancements.

I would argue that development features could be classified as enhancements. IMHO an enhancement classifier would help to bridge the gap between fix and feature. E.g. a fix indicates that there must have been a bug before. A feature indicates that there is some added functionality or business value. But often I find myself to commit changes which improve some situation but which neither fix a bug nor do they add a feature.

E.g. performance usually is a non-functional requirement and can't be classified as a feature from a customer's perspective. Improving performance is usually more of an enhancement than a feature.

@about-code commented on GitHub (Jan 13, 2018): I would prefer to see something like `enhance` to classify *enhancements*. I would argue that development features could be classified as enhancements. IMHO an enhancement classifier would help to bridge the gap between *fix* and *feature*. E.g. a *fix* indicates that there must have been a bug before. A *feature* indicates that there is some added functionality or business value. But often I find myself to commit changes which improve some situation but which neither fix a bug nor do they add a feature. E.g. performance usually is a non-functional requirement and can't be classified as a feature from a customer's perspective. Improving performance is usually more of an enhancement than a feature.

GiteaMirror commented

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

@damianopetrungaro commented on GitHub (May 2, 2018):

We did it some days ago :D #25 !

Thanks to @about-code and @AoDev for the great idea!

@damianopetrungaro commented on GitHub (May 2, 2018): We did it some days ago :D #25 ! Thanks to @about-code and @AoDev for the great idea!

GiteaMirror commented

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

@about-code commented on GitHub (May 5, 2018):

@damianopetrungaro Thanks to @blackxored and you for writing it into the spec!

@about-code commented on GitHub (May 5, 2018): @damianopetrungaro Thanks to @blackxored and you for writing it into the spec!

GiteaMirror referenced this issue