Hotfix, Patch and Release

Hotfix, patch, release — three speeds of change, three levels of ceremony. A hotfix is the emergency lane: a critical fix shipped fast, process-lite, reviewed hard afterwards. A patch is scheduled repair; a release is planned progress. Knowing which lane a change belongs in — and enforcing the lanes — is most of change discipline in practice.

What It Is

A hotfix (or quick-fix engineering patch) is an urgent correction to production for critical defects or security vulnerabilities: minimal scope, expedited approval, shipped as soon as verified, with the full documentation and review completed after the fire is out. A patch is a lesser planned change — a bug fix or security update delivered through the normal cycle; vendors deliver them on cadence (patch Tuesday being the famous convention). A release is a planned delivery of features and fixes through the full pipeline. The hotfix paradox: it bypasses exactly the controls that prevent bad changes, so its justification bar must be genuinely high and its aftermath mandatory — every hotfix reviewed for how the defect escaped and how the emergency was created.

Why It Matters to You

Hotfix frequency is one of the cleanest health metrics in engineering: a team hotfixing weekly is either running systems beyond its discipline or shipping recklessly — both are findings. The executive disciplines: insist hotfixes are rare, justified in writing, and always followed by review; watch patch cadence on software you buy (see End-of-Life for what happens when it stops); and in vendor contracts, distinguish response times (how fast they react) from fix times (how fast it is resolved) — the SLA definitions that conflate them are the ones that disappoint.

When You'll Meet It

In incident reviews, SLA definitions, and release governance. The hotfix log, read quarterly, tells you where quality actually stands.