mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2026-03-22 12:44:37 -05:00
Why Do We Recommend improvement As A Type
#37
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/conventionalcommits.org#37
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hutson on GitHub (Aug 19, 2018).
Continuing the conversation from - https://github.com/conventional-commits/conventionalcommits.org/issues/66#issuecomment-410618044
Why do we recommend
improvementas a type, and how isimprovementbetter than using other types that signify improvements noticeable to downstream consumers, such asperf?@damianopetrungaro commented on GitHub (Aug 20, 2018):
As you can see I do not agree with the usage of refactor with a BREAKING CHANGE: into it, it's a contradiction imho 😄I think it's more about lexical meaning of the words.
performance-> it's about performancerefactor-> it's about refactoring and itSHOULD NOTintroduce BCimprovement-> it's like a refactor with interal BC.I am totally open about discussing to remove/change it.
@Mouvedia commented on GitHub (Aug 28, 2018):
In short
improvementcovers refactors that are not performance improvements.e.g. readability, dead code removal (for compiled languages), algorithm replacement
Which means that the
refactortype will only cover refactors that have a negative or neutral impact.Would JSDoc comments be covered by
docs?What would be the scope of improvement?
Do you have other examples?
Unless we provide a clear definition of improvement we should drop it and limit ourselves to these.
@damianopetrungaro commented on GitHub (Aug 28, 2018):
@Mouvedia we should NOT depend on external tools to decide about which type use.
See that the specs only support
feat&fixand the usage of improvement is already described in the specswhat we can do is add an example and add a section to the FAQ.
Or maybe rephrase the current explanation.
@Mouvedia commented on GitHub (Aug 28, 2018):
Recommendations should not conflict with existing conventions that's all I am saying or it should perfectly cover the existing ones. If the lines are blurred it would introduce uncertainty and that's not desired.
@damianopetrungaro commented on GitHub (Oct 13, 2018):
@Mouvedia @hbetts any update on this?
@Mouvedia commented on GitHub (Oct 13, 2018):
improvementan improvement over multiple types (perf,refactor, etc.)?@AoDev commented on GitHub (Jan 11, 2019):
Hi,
A long time ago I submitted a question about the
meaning of feat, here for context: https://github.com/conventional-commits/conventionalcommits.org/issues/26I just recently discovered the new "improvement" tag recommendation. Maybe it came from my original question(?) That said, to answer @Mouvedia questions:
Since my own question, I have been using the tag "imp", as "improvement", in all my projects.
The typical usage of this tag is when I improve the internal libraries of my apps. Libraries that could well be standalone and published as separate packages, but not worth the hassle until a second project requires them.
Cases where I do this:
Example:
asyncUtils.js(an already existing collection of utilities to manage async code)I find myself needing a new async utility to create a new feature, that would lead to two commits:
imp(asyncUtils): added new function...feat(app): new feature that uses the new async utilityIn summary: any added functionality to the "internals" of the app or library that is irrelevant to the end-user. They don't qualify as
featnorrefactor.I have been doing this for one year now. It works pretty well because I can generate changelog for end-users from
featandfixwhile keeping track of internal improvements and better split commits. And I find it funny, it makes me think of fairies. :P@Mouvedia commented on GitHub (Jan 11, 2019):
Alright here's my take based on your description:
@AoDev Anything to add?
@AoDev commented on GitHub (Jan 11, 2019):
@Mouvedia Yes that's a good definition of what I have in my head. Especially your last point is spot on I would say.
@Mouvedia commented on GitHub (Jan 11, 2019):
This shit is goddamn narrow in scope. Would
internalbe more encompassing and easier to describe?@AoDev commented on GitHub (Jan 11, 2019):
I don't think it's a "goddamn narrow in scope".
If I look at my last project (medium size SPA)
Commits count go like this:
imp: 86
refactor: 72
feat: 70
fix: 41
It's the most used tag. Obviously it depends on app architecture. Personally I set a clear line between business logic (would lead to
feat) and generic stuff (leads toimp).@damianopetrungaro commented on GitHub (Feb 8, 2019):
Closing this due to inactivity.
Feel free to re-open it if needed! 😄
@karol-depka commented on GitHub (Jun 19, 2020):
Please use
improve; much shorter thanimprovementwhile still an englishword* with its own clear meaning. Please don't play this game of crazy abbreviations.Imp, for example, can stand for so many different things, includingimplementation, it's scr*wing with your brain. Shock Minimization Principle. Imagine someone new coming to a project and seeing a bunch ofimp(implementation?) orimprov(improvised solution?); must seem crazy and confusing at the beginning. We should reduce barriers and confusions, not create new ones. Please upvote if You agree! :) Common sense FTW!This whole over-shortening game is a bit like Perl's Akka's crazy special-chars operators... ...considered harmful.
Thank You for Your work on trying to standardize commit messages :).
@rcdailey commented on GitHub (May 27, 2021):
Why not
change? As far as this discussion goes, my suggestion is relevant for me personally because:1.5.1instead of1.6.0(going from1.5.0).Either way, in my case, I personally will go with:
@damianopetrungaro commented on GitHub (Jun 9, 2021):
@rcdailey to me
changeis too vague, it may include any other scope as well which kinda conflict with the conventional commit purpose.@anburocky3 commented on GitHub (Apr 3, 2022):
So do you guys decided? 🤣 Looks like multiple discussion going around and what did you guys decided at the end?
I personally feel,
improve:is okay, other terms likeimp:,immakes confusions@ftzi commented on GitHub (Jun 5, 2022):
I have a login system. The loading modal was only being shown after some steps, where it could be shown earlier. I improved it and it's now being shown properly.
It wasn't a bug so it isn't a
fix. It isn't afeatbecause it already existed.I ain't yet too familiar with Conventional Commits, so I googled "conventional commits improvement" and got here.
+1 for
improve:@melsabagh commented on GitHub (Jan 13, 2023):
Hate to flog a dead horse, but what's wrong with
enh:for enhancement/improvement?@martin-braun commented on GitHub (Jan 25, 2023):
I think we should reopen this for cases like making a few things better in the UI so it becomes easier for the user, or when updating translations to give better information to the user. It's not really a feature, because it doesn't bring something new to the table. It's also not fixing something, it's just improving something.
enh,enhance,impr,improve, whatever will it be. A common standard is what I like and would really love to see.@tobias-edwards commented on GitHub (Jan 25, 2023):
Sounds like
improvementis being suggested as a minorfeatorfix- atweak, if you will.Or it's being suggested as the type that describes smaller commits that forms part of a
featorfixpull request.Do we want/need this granularity? Commit messages should be easy to write, I don't want to enter a state of analysis paralysis everytime I commit something small:
Is this an improvement? All features and fixes are improvements. Is this big enough to be a feature/fix? Etc.
@AoDev commented on GitHub (Jan 25, 2023):
Years have passed since I got interested in this question. I've changed my strategy since then and wanted to share it here for anyone interested.
I combine the chore tag with the others.
For example a fix in some internal framework becomes
chore: fix(something): ...or justchore: fix: descriptionAnother example would be an improvement in the UI but not worth being listed as a public new feature in a changelog. (example in previous comments)
chore: feat(login): bigger button for better UXBasically prefixing with
chorewhat would be the actual thing if it were public and still following the guidelines of conventional commits. (Angular flavour)If there is ever a new official tag recommended, great :)
@melsabagh commented on GitHub (Jan 25, 2023):
@AoDev Does
choreget mapped to anything when bumping? The tools I have tried don't bump onchorechanges.@ftzi commented on GitHub (Jan 25, 2023):
I actually like
tweak@Mouvedia commented on GitHub (Jan 25, 2023):
👍 for tweak
@martin-braun commented on GitHub (Jan 25, 2023):
tweakwould be a great addition to the open standard.@ftzi commented on GitHub (Jan 30, 2023):
@damianopetrungaro can you reopen this due to this good (and quite unexpected)
tweaksuggestion? Thanks!@DoctorDerek commented on GitHub (Feb 2, 2023):
They're features (
feat) unless you've identified a clear usability (user experience / UX) or accessibility (a11y) defect, in which case the enhancement is a bugfix (fix).@martin-braun commented on GitHub (Feb 12, 2023):
@DoctorDerek I let that sink in for a while and I think you are right. If you have a
tweakask yourself, does it solve a mis-alignment, then it's afix, does it add something new in a minor fashion, then it's a minorfeat.