Support for hotfixes? #185

New Issue

GiteaMirror · 2026-02-17T11:52:21-06:00

GiteaMirror commented

2026-02-17 11:52:21 -06:00

Originally created by @paul-uz on GitHub (Aug 24, 2023).

What should we do for a hotfix? Use fix? Or can we have a specific hotfix type added?

Originally created by @paul-uz on GitHub (Aug 24, 2023). What should we do for a hotfix? Use `fix`? Or can we have a specific `hotfix` type added?

GiteaMirror commented

2026-02-17 11:52:23 -06:00

@mentalisttraceur commented on GitHub (Aug 24, 2023):

Another example of something that would be well-served by #537 .

@mentalisttraceur commented on GitHub (Aug 24, 2023): Another example of something that would be well-served by #537 .

GiteaMirror commented

2026-02-17 11:52:23 -06:00

@mentalisttraceur commented on GitHub (Aug 24, 2023):

I don't think it's a common-enough use-case to go into the core spec, but some projects have good reason to make the distinction between fixes-that-can-wait and fixes-that-need-to-go-in-now. So I can see at least two good reasons to have a hotfix change type distinct from a fix type:

A hotfix change type with semantics like "bypass the normal pipeline (for example, any/all of: don't do the full slow testing; don't reject if the linter complains; fire off the release pipeline; exclude all non-hotfix changes merged since last release)".
A hotfix change type with semantics like "this is like fix, but it is retroactively going into the most recent version, not into the next version (so tooling which automatically increments the version should treat it differently)".
- I've worked with teams who don't like releasing hotfixes as new versions. You release 1.2.0, discover a bug, roll out a hotfix. A machine labels that 1.2.1 without a second thought. A human versed in office politics and image games thinks 1.2.1 might look bad and prefers to re-release as 1.2.0.

@mentalisttraceur commented on GitHub (Aug 24, 2023): I don't think it's a common-enough use-case to go into the core spec, but some projects have good reason to make the distinction between fixes-that-can-wait and fixes-that-need-to-go-in-now. So I can see at least two good reasons to have a `hotfix` change type distinct from a `fix` type: 1. A `hotfix` change type with semantics like "bypass the normal pipeline (for example, any/all of: don't do the full slow testing; don't reject if the linter complains; fire off the release pipeline; exclude all non-hotfix changes merged since last release)". 2. A `hotfix` change type with semantics like "this is like `fix`, but it is retroactively going into the most recent version, not into the next version (so **tooling which automatically increments the version should treat it differently**)". * I've worked with teams who don't like releasing hotfixes as new versions. You release 1.2.0, discover a bug, roll out a hotfix. A machine labels that 1.2.1 without a second thought. A human versed in office politics and image games thinks 1.2.1 might look bad and prefers to re-release as 1.2.0.

GiteaMirror commented

2026-02-17 11:52:24 -06:00

@paul-uz commented on GitHub (Aug 24, 2023):

For me, a hotfix only ever increments the patch version, based on gitflow.

I think it's used by enough software developers/teams that it would be a great fit inthe core spec

@paul-uz commented on GitHub (Aug 24, 2023): For me, a hotfix only ever increments the patch version, based on gitflow. I think it's used by enough software developers/teams that it would be a great fit inthe core spec

GiteaMirror commented

2026-02-17 11:52:25 -06:00

@mentalisttraceur commented on GitHub (Aug 24, 2023):

a hotfix only ever increments the patch version, based on gitflow.

Right, which means you at most want the 1st semantic I mentioned, and never the 2nd. That makes it more like a fix, and many teams would be happy to just use fix for that.

If I was designing a CCRFI for this, I'd make the 2nd semantic optional. For example, I might propose that tools by default treat hotfix as bumping the version just like fix does, but also implement a flag or environment variable which flips on "hotfix does not bump version" behavior.

Re: core spec fit: I agree that hotfixes are a very common distinction for teams to make in their commits, and if Conventional Commits was a "thicker" spec, I'd agree that hotfix should be in it! But looking at all the context clues, I infer that Conventional Commits is intended to be the smallest-viable-foundation for two goals: a parseable commit format, and mapping commits to SemVer semantics. The core only defines feat and fix change types, actively encourages extensions, and has never merged any of the community suggestions for other change types into core.

@mentalisttraceur commented on GitHub (Aug 24, 2023): > a hotfix only ever increments the patch version, based on gitflow. Right, which means you at most want the 1st semantic I mentioned, and never the 2nd. That makes it more like a `fix`, and many teams would be happy to just use `fix` for that. If I was designing a CCRFI for this, I'd make the 2nd semantic optional. For example, I might propose that tools by default treat `hotfix` as bumping the version just like `fix` does, but also implement a flag or environment variable which flips on "hotfix does not bump version" behavior. Re: core spec fit: I agree that hotfixes are a very common distinction for teams to make in their commits, and if Conventional Commits was a "thicker" spec, I'd agree that `hotfix` should be in it! But looking at all the context clues, I infer that Conventional Commits is intended to be the smallest-viable-foundation for two goals: a parseable commit format, and mapping commits to SemVer semantics. The core only defines `feat` and `fix` change types, actively encourages extensions, and has never merged any of the community suggestions for other change types into core.

GiteaMirror commented

2026-02-17 11:52:26 -06:00

@paul-uz commented on GitHub (Aug 25, 2023):

Lets see what the repo owner/maintainers say.

@paul-uz commented on GitHub (Aug 25, 2023): Lets see what the repo owner/maintainers say.

GiteaMirror commented

2026-02-17 11:52:27 -06:00

@leafknode commented on GitHub (Feb 20, 2025):

A little necromancy here but I came across this issue when searching for whether hotfix was a valid conventional commit. I'm also on the side that it would be a value add, particularly in the context of tracking DORA Change Failure Rate. While it's possible to track this through your issue tracking system (Jira, etc), I'd prefer to do this at the code level so that the commit is also distinctly different from a fix

@leafknode commented on GitHub (Feb 20, 2025): A little necromancy here but I came across this issue when searching for whether `hotfix` was a valid conventional commit. I'm also on the side that it would be a value add, particularly in the context of tracking DORA Change Failure Rate. While it's possible to track this through your issue tracking system (Jira, etc), I'd prefer to do this at the code level so that the commit is also distinctly different from a `fix`

GiteaMirror commented

2026-02-17 11:52:28 -06:00

@MossPalmer-POL commented on GitHub (May 15, 2025):

From a versioning point of view. Assuming that a hotfix can use the patch alone is misguided.
If I release 1.0.0 of my software, then develop/merge a fix (1.0.1) then before that's released we work on a critical issue in prod that needs resolving, I can't reuse the 1.0.1 tag, I'd need something in between, hence something like 1.0.0+hotfix.1

@MossPalmer-POL commented on GitHub (May 15, 2025): From a versioning point of view. Assuming that a hotfix can use the patch alone is misguided. If I release 1.0.0 of my software, then develop/merge a fix (1.0.1) then before that's released we work on a critical issue in prod that needs resolving, I can't reuse the 1.0.1 tag, I'd need something in between, hence something like 1.0.0+hotfix.1

GiteaMirror commented

2026-02-17 11:52:29 -06:00

@paul-uz commented on GitHub (May 15, 2025):

From a versioning point of view. Assuming that a hotfix can use the patch alone is misguided. If I release 1.0.0 of my software, then develop/merge a fix (1.0.1) then before that's released we work on a critical issue in prod that needs resolving, I can't reuse the 1.0.1 tag, I'd need something in between, hence something like 1.0.0+hotfix.1

surely you'd use 1.0.2?

@paul-uz commented on GitHub (May 15, 2025): > From a versioning point of view. Assuming that a hotfix can use the patch alone is misguided. If I release 1.0.0 of my software, then develop/merge a fix (1.0.1) then before that's released we work on a critical issue in prod that needs resolving, I can't reuse the 1.0.1 tag, I'd need something in between, hence something like 1.0.0+hotfix.1 surely you'd use 1.0.2?

GiteaMirror commented

2026-02-17 11:52:30 -06:00

@kamilzzz commented on GitHub (Jun 17, 2025):

If I release 1.0.0 of my software, then develop/merge a fix (1.0.1) then before that's released we work on a critical issue in prod that needs resolving, I can't reuse the 1.0.1 tag, I'd need something in between, hence something like 1.0.0+hotfix.1

Maybe if it is not released yet it should not have any semver assigned?

Then you simply hotfix and release 1.0.1, probably include hotfix on your main branch, and if you are ready to release new version you either use 1.1.0 - as I guess in the meantime you developed some new features, or 1.0.2 if new release is indeed only bugfix.

@kamilzzz commented on GitHub (Jun 17, 2025): > If I release 1.0.0 of my software, then develop/merge a fix (1.0.1) then before that's released we work on a critical issue in prod that needs resolving, I can't reuse the 1.0.1 tag, I'd need something in between, hence something like 1.0.0+hotfix.1 Maybe if it is not released yet it should not have any semver assigned? Then you simply hotfix and release 1.0.1, probably include hotfix on your main branch, and if you are ready to release new version you either use 1.1.0 - as I guess in the meantime you developed some new features, or 1.0.2 if new release is indeed only bugfix.

GiteaMirror referenced this issue

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

[PR #185] [MERGED] feat: reduce ambiguity around footer/body #346

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#185