mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2026-03-23 06:01:43 -05:00
Is there an abbr for improvement?
#28
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/conventionalcommits.org#28
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 @htchaan on GitHub (Jul 9, 2018).
Originally assigned to: @damianopetrungaro on GitHub.
Since
improvement(11 chars) is even longer thanfeature(7 chars), which is shortened asfeat.@damianopetrungaro commented on GitHub (Jul 9, 2018):
Hey @htchaan thank you for the question!
I think it's quite long too, but at the moment there's no abbreviation for
improvement, if you have a good idea feel free to suggest and discuss here in the issue!Good ideas are always welcome 😄
@pmackay commented on GitHub (Jul 16, 2018):
Would
improvebe an improvement onimprovement? ;)@damianopetrungaro commented on GitHub (Jul 18, 2018):
@pmackay I think
improveis more a verb than a noun.Any other suggestion?
@htchaan commented on GitHub (Jul 19, 2018):
I vote for
impr. Its 4-char just like many other abbreviations eg.elem,feat,impl.Damiano Petrungaro notifications@github.com 於 2018年7月19日週四 上午12:49寫道：
@damianopetrungaro commented on GitHub (Jul 19, 2018):
@hbetts @stevemao @bcoe wdyt about it?
@hutson commented on GitHub (Jul 19, 2018):
I didn't realize we recommended
improvement.Honestly, if it's a code change, then the only non-feature, non-bug, improvement would be a performance one, and for that you could use the Angular convention of
perf.Basically, I'm taking a step back and asking, do we even need improvement? What does it communicate that feat, fix, and perf, do not?
@pmackay commented on GitHub (Jul 21, 2018):
What would a refactoring for code cleanup fit under?
@hutson commented on GitHub (Jul 22, 2018):
The Conventional Commits documentation states:
for example commitlint-config-conventional (based on the the Angular convention) recommends chore:, docs:, style:, refactor:So I personally use
refactor, and the communities I work with userefactor, for code changes that do not add a feature, address a bug, or improve performance.@damianopetrungaro commented on GitHub (Jul 23, 2018):
Hey!
Sorry but I had a weekend without internet 😄
@hbetts I suggested some months ago to introduce
improvement, becauserefactormeans it MUST NOT introduce any breaking changes.Instead
improvementit's ok with API changes but does not introduce any external BC.I am totally open to rediscuss it!
edit:
btw, just to underline the concept, we should not stick 1:1 to the Angular convention, we are inspired by, not equals to 😄
@hutson commented on GitHub (Aug 5, 2018):
I think I've used
refactorin the past for breaking changes.For example, I will deprecate a function as part of a
patch, but I won't remove it.Then, at a later time, I will remove that function in a
refactor, with aBREAKING CHANGEcomment at the bottom of my commit message, explaining the removal, and the recommended migration path. I userefactorbecause I'm not adding a feature, and I don't consider removing a deprecated function as a bugfix.I'm sorry if I'm derailing this issue. If y'all would like my thoughts on
improvement, or additional personal examples, please let me know where I can post them.As for abbreviation, yes, I would be fine with the recommendations. In particular,
impr, because I kind of agree with @damianopetrungaro about the other being more of averb.Any way to quantify the common abbreviated form of
improvementas used by English language writers?@damianopetrungaro commented on GitHub (Aug 6, 2018):
@hbetts I'm totally fine about talking about it, our mission is to make the specs as better as possible 😄
As you can see I do not agree with the usage of
refactorwith aBREAKING CHANGE:into it, it's a contradiction imho 😄Looking forward to any English native speaker about it
@hutson commented on GitHub (Aug 19, 2018):
I've spun off a discussion about
improvementinto #78As for this issue, I don't have the time to research whether
impris the common abbreviation ofimprovement.Does anyone else have time?
@damianopetrungaro commented on GitHub (Aug 20, 2018):
@hbetts I can take a look tomorrow ;)
@damianopetrungaro commented on GitHub (Aug 26, 2018):
So after a little research, I found out we may use IMPROV or IMP
@Mouvedia commented on GitHub (Aug 26, 2018):
https://en.wikipedia.org/wiki/Imp
@bcoe commented on GitHub (Mar 31, 2019):
👋 any objection to closing this pull request, I think the spec appropriately calls out the fact that folks can pick and choose their own types.
@Mouvedia commented on GitHub (Mar 31, 2019):
I think we should close this one and reopen #78
@stevemao commented on GitHub (Apr 1, 2019):
Closing now. Feel free to comment.
@batara666 commented on GitHub (Oct 13, 2021):
wait, so are we using imp: ?
@batara666 commented on GitHub (Oct 13, 2021):