This could cause an immediate loss of services, so depending on the severity of the bug, it may be desirable to delay a hotfix. The risk of applying the hotfix must be weighed against the risk of not applying it, because the problem to be fixed might be so critical that it could be considered more important than a potential loss of service (e.g., a major security breach).
- not released to a schedule.
- intended to address either 'niche' situations or 'emergency' responses.
- only relevant to the specific issue documented in the release notes.
- poorly tested. If at all.
- a potential source for the (re)introduction of bugs.
- intended for small audiences.
- likely to affect automated patching systems and require additional monitoring. Hotfixes may deploy a file/library with unusually high version number to prevent the hotfix from being patched over.
- supplied by the software maker directly to named contacts, not publically available. Customers are often expected to contact technical support to request hotfixes for example.
- frequently branched from the 'last known good' source tree. As a 'quick fix' the code used in the hotfix may never make it back into the main build (it may be that as a temporary fix a better solution requires more time/resources.)