About the meanings of "feat" about conventionalcommits.org HOT 7 CLOSED

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.

from conventionalcommits.org.

We did it some days ago :D #25 !

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

from conventionalcommits.org.

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.

from conventionalcommits.org.

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.

from conventionalcommits.org.

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

from conventionalcommits.org.

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.

from conventionalcommits.org.

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

from conventionalcommits.org.