Giters

conventional-commits / conventionalcommits.org

The conventional commits specification

Home Page:https://conventionalcommits.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for hotfixes?

paul-uz opened this issue · comments

commented

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

commented

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

commented

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.
commented

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

commented

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.

commented

Lets see what the repo owner/maintainers say.