About the meanings of "feat"

[AoDev]

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

[stevemao]

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.

[AoDev]

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". angular/angular.js@2e03aed

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.

[stevemao]

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.

[AoDev]

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

[about-code]

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.

[damianopetrungaro]

We did it some days ago :D #25 !

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

[about-code]

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