Allow patch as an alternative/alias to fix #167

New Issue

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

GiteaMirror commented

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

Originally created by @lzambarda on GitHub (Jan 17, 2023).

While reading v1.0.0 I noticed the following:

fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).

This is a good description because as developers we patch things more often than we fix them (a level of uncertainty in having fixed certain bugs is not uncommon).

Therefore I would argue that patch should be allowed as an alternative to fix if not even used as a replacement.

Originally created by @lzambarda on GitHub (Jan 17, 2023). While reading v1.0.0 I noticed the following: > fix: a commit of the type fix **patches** a bug in your codebase (this correlates with [PATCH](http://semver.org/#summary) in Semantic Versioning). This is a good description because as developers we patch things more often than we fix them (a level of uncertainty in having fixed certain bugs is not uncommon). Therefore I would argue that `patch` should be allowed as an alternative to `fix` if not even used as a replacement.

GiteaMirror commented

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

@bcoe commented on GitHub (Jan 30, 2023):

The challenge with aliasing the foundational types (fix and feat), is that there's a significant ecosystem of tooling that exists already for conventional commits.

Perhaps we could instead provide more direction in the non-normative text, about how to use alternative types? If in your project you would prefer to use patch to fix, this is perfectly reasonable if you can get your toolchain setup to handle it -- I'm hesitant to overhaul the normative text of the spec to handle this behaviour...

I think I feel the same way regarding using feature, rather than feat, which I used to be supportive of. This spec has been in the wild for a few years now, there's a healthy amount of tooling around it, and I think it's serving its purpose well.

This is just one opinion though!

@bcoe commented on GitHub (Jan 30, 2023): The challenge with aliasing the foundational types (`fix` and `feat`), is that there's a significant ecosystem of tooling that exists already for conventional commits. Perhaps we could instead provide more direction in the non-normative text, about how to use alternative types? If in your project you would prefer to use `patch` to `fix`, this is perfectly reasonable if you can get your toolchain setup to handle it -- I'm hesitant to overhaul the normative text of the spec to handle this behaviour... _I think I feel the same way regarding using `feature`, rather than `feat`, which I used to be supportive of. This spec has been in the wild for a few years now, there's a healthy amount of tooling around it, and I think it's serving its purpose well._ This is just one opinion though!

GiteaMirror referenced this issue

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

[PR #167] [MERGED] docs: update Korean translation #334

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#167

Allow patch as an alternative/alias to fix #167

Allow `patch` as an alternative/alias to `fix` #167