What type should be used for small improvements?

[Yurii Brusentsov]

Sometimes I have changes that are not a new feature itself, but a small addition to current functionality.
feat: and fix: seems like not the best types for this case.

I think something like imp: (an abbreviation of improvement:) should fit great in cases like this.
CHANGELOGs can generate the improvements section based on these commits.

What do you think?

[Alex]

I think scoping the commit type would be the solution to that with the current convention
Example: feat(loading-button): made button disabled while loading

[Yurii Brusentsov]

Scoped feat type can be used in this case, but it will force a new minor release according to the docs:

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

[Damiano Petrungaro]

It depends what you are improving @goveo :D
If the improve is a performance issue, fix should be the type since also reflects the minor release in SemVer.

If the improve you're doing is building a functionality (example changing the color of a button while loading), then it is a feat :)

[Javier Godoy]

Sometimes it can be argued that the change in question is a fix: if users can open the same file multiple times by clicking the load button repeatedly (because it is not disabled), which is a behavior that does not provide any value to the users and should not be allowed by the application, then disabling the button while loading can be considered more of fix than a feat.

I've been using conventional-commits mostly with reusable components, and found that the difference between fix and feat is clear-cut, and aligns well with SemVer. With applications/products, however, it's a different story:

• There are small features (add a "second email" field to the users table) and big features (implement a module for managing customer subscriptions). The difference between small and big features is not of a technical nature: both add behaviors that were not present on the previous version.
• SemVer defines change levels according to how the "public API" is affected, but the application may expose no public API at all, or it may only expose a subset of features, thus many changes that are strictly "new features" result in no changes to the "public API". There is some discussion about it in semver/semver#323
• "Semantic Versioning is all about conveying meaning by how the version number changes. If these changes are important to your users, use the version number to inform them." [1]
• The minor version "MAY [but not MUST] be incremented if substantial new functionality or improvements are introduced within the private code" [2], which gives you some leeway on how to map "features" to minor/patch (although conventional-commits still specifies that feat aligns with MINOR)