What type should be used for small improvements?
goveo opened this issue · 4 comments
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?
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
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
:)
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)