github-starred/conventionalcommits.org
2
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2026-05-24 06:40:53 -05:00
Code Issues 1.7k Packages Projects Releases Wiki Activity

What is a bug? #221

New Issue
Open
opened 2026-02-17 11:54:33 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-02-17 11:54:33 -06:00
Owner
Copy Link

Originally created by @dabaus on GitHub (Mar 11, 2025).

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). 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?
GiteaMirror added the discussion label 2026-02-17 11:54:34 -06:00
GiteaMirror commented 2026-02-17 11:54:36 -06:00
Author
Owner
Copy Link

@rbalet commented on GitHub (Apr 10, 2025):

He @dabaus .

TLDR;

Bug is ment to be named fix.

-> To know more, read the angular documentation

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
@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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
discussion
enhancement
greenkeeper
help wanted
meeting-agenda
operations
process
pull-request
Mirrored from GitHub Pull Request
 question
suggestion
support
triaged
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#221
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?