What type should be used for small improvements? #166

New Issue

GiteaMirror · 2026-02-17T11:50:52-06:00

GiteaMirror commented

2026-02-17 11:50:52 -06:00

Originally created by @ybrusentsov on GitHub (Jan 14, 2023).

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?

Originally created by @ybrusentsov on GitHub (Jan 14, 2023). 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?

GiteaMirror commented

2026-02-17 11:50:53 -06:00

@prenaissance commented on GitHub (Jan 18, 2023):

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

@prenaissance commented on GitHub (Jan 18, 2023): 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`

GiteaMirror commented

2026-02-17 11:50:54 -06:00

@ybrusentsov commented on GitHub (Jan 18, 2023):

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

@ybrusentsov commented on GitHub (Jan 18, 2023): Scoped `feat` type can be used in this case, but it will force a new minor release according to the [docs](https://www.conventionalcommits.org/en/v1.0.0/#:~:text=feat%3A%20a%20commit%20of%20the%20type%20feat%20introduces%20a%20new%20feature%20to%20the%20codebase%20(this%20correlates%20with%20MINOR%20in%20Semantic%20Versioning).): > feat: a commit of the type feat introduces a new feature to the codebase (this correlates with [MINOR](http://semver.org/#summary) in Semantic Versioning).

GiteaMirror commented

2026-02-17 11:50:55 -06:00

@damianopetrungaro commented on GitHub (Jan 25, 2023):

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

@damianopetrungaro commented on GitHub (Jan 25, 2023): 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` :)

GiteaMirror commented

2026-02-17 11:50:56 -06:00

@javier-godoy commented on GitHub (Feb 12, 2023):

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 https://github.com/semver/semver/issues/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)

@javier-godoy commented on GitHub (Feb 12, 2023): 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 https://github.com/semver/semver/issues/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]](https://semver.org/#what-if-i-inadvertently-alter-the-public-api-in-a-way-that-is-not-compliant-with-the-version-number-change-ie-the-code-incorrectly-introduces-a-major-breaking-change-in-a-patch-release) - The minor version "MAY [but not MUST] be incremented if substantial new functionality or improvements are introduced within the private code" [[2]](https://semver.org/#spec-item-7), which gives you some leeway on how to map "features" to minor/patch (although conventional-commits still specifies that `feat` aligns with MINOR)

GiteaMirror referenced this issue

2026-02-17 11:59:29 -06:00

[PR #166] [MERGED] Update IT translation #333

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#166