Breaking changes follow semver
Why it matters
Renaming a hook, changing its payload shape, or removing a plugin context method without a major version bump breaks every plugin in the ecosystem instantly and silently. Plugin authors discover the change when their code crashes, not from a deprecation warning or migration guide. ISO 25010 maintainability.modifiability requires that the scope of a change be predictable; semver applied to the plugin API is the mechanism that communicates scope. Without it, every minor host release carries hidden risk for the plugin ecosystem.
Severity rationale
High because breaking plugin API changes shipped in minor or patch releases break the installed plugin ecosystem without warning, removing the signal plugin authors rely on to assess upgrade risk.
Remediation
Apply semver discipline to the plugin API independently of the host application version: hook renames or payload changes = major bump; new hooks = minor; behavioral bug fixes = patch. Forward deprecated hook names to their replacements and emit a warning.
on(hook: string, handler: Function) {
if (DEPRECATED_HOOKS[hook]) {
console.warn(
`[PluginAPI] Hook "${hook}" is deprecated and will be removed in API v${
DEPRECATED_HOOKS[hook].removeInVersion
}. Use "${DEPRECATED_HOOKS[hook].replacement}" instead.`
);
hook = DEPRECATED_HOOKS[hook].replacement;
}
// ... register handler
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Plugin / Extension Architecture Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.modifiability — Modifiability — semver discipline for plugin API ensures breaking changes are communicated and manageable
Taxons
History
- 2026-04-18·v1.0.0·Initial import from plugin-extension-architecture·automated