So we had this discussion in our team that fix should basically only be used when there is a bug ticket. And because of that most people tend to use chore for everything except features and refactor, because
chore implies it's not a bug and low impact.
However, i think that anything that changes a feature in production should be regarded as a fix. And the reasoning behind it is that, even if it was the stakeholder that changed the specification, your application is no longer following the specification for this feature. Thus, you should make a fix for that.
Work-arounds for bugs in other systems, might also be a fix.
My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,
But i don't know. What do you think? What is the intention of fix? Do you think the intention is clear in the current document?
Originally created by @dabaus on GitHub (Mar 11, 2025).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/643
So we had this discussion in our team that fix should basically only be used when there is a bug ticket. And because of that most people tend to use chore for everything except features and refactor, because
chore implies it's not a bug and low impact.
However, i think that anything that changes a feature in production should be regarded as a fix. And the reasoning behind it is that, even if it was the stakeholder that changed the specification, your application is no longer following the specification for this feature. Thus, you should make a fix for that.
Work-arounds for bugs in other systems, might also be a fix.
My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,
But i don't know. What do you think? What is the intention of fix? Do you think the intention is clear in the current document?
My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,
let me develop a bit..
chore Things that aren't ment to be part of the versioning such as merging branches, bumping a version -> example : chore(release): publish 1.0.0 (Code automated by nx if you're using it)
build or ci: would be use for your configuration changes or any dependencies updates (In case this configuration is in the ci then -> ci)
feat: feat is a new feature, stubs or classes are part of it, but why would you have a class that is not yet in use -> Sounds to be like a red flag -> YAGNI
docs: If you're updating your readme or any documentations
refactor - style : Things that do not effect production in any way and that does not resolve to the others
<!-- gh-comment-id:2792201558 -->
@rbalet commented on GitHub (Apr 10, 2025):
He @dabaus .
## TLDR;
`Bug `is ment to be named `fix`.
-> To know more, read the [angular documentation](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type)
## To your take
> My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,
let me develop a bit..
- `chore` Things that aren't ment to be part of the versioning such as merging branches, bumping a version -> example : `chore(release): publish 1.0.0` (Code automated by nx if you're using it)
- `build` or `ci`: would be use for your configuration changes or any dependencies updates (In case this configuration is in the ci then -> `ci`)
- `feat`: feat is a new feature, stubs or classes are part of it, but why would you have a class that is not yet in use -> Sounds to be like a red flag -> YAGNI
- `docs`: If you're updating your readme or any documentations
- `refactor` - `style` : Things that do not effect production in any way and that does not resolve to the others
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @dabaus on GitHub (Mar 11, 2025).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/643
So we had this discussion in our team that fix should basically only be used when there is a bug ticket. And because of that most people tend to use chore for everything except features and refactor, because
chore implies it's not a bug and low impact.
However, i think that anything that changes a feature in production should be regarded as a fix. And the reasoning behind it is that, even if it was the stakeholder that changed the specification, your application is no longer following the specification for this feature. Thus, you should make a fix for that.
Work-arounds for bugs in other systems, might also be a fix.
My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,
But i don't know. What do you think? What is the intention of fix? Do you think the intention is clear in the current document?
@rbalet commented on GitHub (Apr 10, 2025):
He @dabaus .
TLDR;
Bugis ment to be namedfix.-> To know more, read the angular documentation
To your take
let me develop a bit..
choreThings that aren't ment to be part of the versioning such as merging branches, bumping a version -> example :chore(release): publish 1.0.0(Code automated by nx if you're using it)buildorci: would be use for your configuration changes or any dependencies updates (In case this configuration is in the ci then ->ci)feat: feat is a new feature, stubs or classes are part of it, but why would you have a class that is not yet in use -> Sounds to be like a red flag -> YAGNIdocs: If you're updating your readme or any documentationsrefactor-style: Things that do not effect production in any way and that does not resolve to the others