Plugin API changelog maintained
Why it matters
When plugin API changes are buried in general commit history or a changelog that does not distinguish plugin-API-affecting changes from UI tweaks and bug fixes, plugin authors have no reliable way to know what changed between host versions. They discover breaking changes when their plugin crashes in production after a host upgrade. ISO 25010 maintainability.modifiability requires that the impact of modifications be traceable; a plugin API changelog is the traceability artifact that makes API evolution navigable for the plugin ecosystem.
Severity rationale
Low because an unmaintained plugin API changelog forces authors to read every commit between host versions to assess upgrade risk, making plugin maintenance expensive and driving authors to avoid upgrades.
Remediation
Create a dedicated docs/plugin-api-changelog.md or a clearly marked section in CHANGELOG.md. Every release that adds, modifies, or deprecates a hook or plugin context method must include an entry.
## v2.1.0
- Added `onBeforeRender` hook — fires before each page render with `{ url, context }`
- Deprecated `onRender` — use `onAfterRender` instead; `onRender` removed in v3.0.0
## v2.0.0 (breaking)
- Renamed `beforeRequest` payload field `req` to `request`
- Removed `onLoad` hook — migrate to `init()` lifecycle method
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 — a dedicated plugin API changelog enables plugin authors to adapt to host changes without breaking silently
Taxons
History
- 2026-04-18·v1.0.0·Initial import from plugin-extension-architecture·automated