Loading page
About this tool
Generate a consumer impact checklist and risk score before shipping an API or library breaking change.
This tool generates a phased consumer-impact checklist — before, release and after — for an API or library breaking change, along with a 0-100 risk score built from the change type, affected surfaces, audience and mitigations you select. It encodes the SemVer 2.0.0 rule that any incompatible public API change requires a major version bump, and the deprecate-warn-remove lifecycle that mature platforms use. Maintainers get a copyable Markdown checklist ready to paste into an issue or RFC.
Open Breaking Change Impact Checklist on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Items are grouped into Before, Release and After so nothing lands unannounced or unmonitored.
Every weight and mitigation credit is a named constant — the same inputs always score the same.
Exports as a - [ ] task list that pastes directly into GitHub issues, RFCs or release plans.
Anything that makes previously valid consumer code or requests stop working or behave differently: removing or renaming public functions, endpoints, flags or fields; changing signatures, types or response shapes; changing documented behaviour or defaults; altering wire or config formats; and raising runtime or dependency requirements. SemVer 2.0.0 item 8 requires a major version bump for all of them.
Not under SemVer for packages at 1.0.0 or above — item 8 reserves incompatible changes for major releases, and consumers using caret ranges will auto-install your minor releases assuming compatibility. The only exception is major version zero (0.x), where item 4 allows anything to change; the convention there is to signal breakage in the minor digit.
There is no universal number; the norm is at least one full major release cycle with runtime warnings, and public platforms commonly give calendar guarantees — for example Google's stable API policies promise a year or more of notice for many products. The right length depends on how fast your consumers actually upgrade, which is why the checklist pushes usage telemetry before removal.
It sums fixed weights for each selected change type (removal and wire-format changes weigh 30, behaviour changes 25, signature changes 20, renames and config changes 15, platform bumps 10), adds 5 per extra affected surface, multiplies by an audience factor (0.5 internal, 0.8 company-wide, 1.0 public), then subtracts mitigation credits such as 15 for a deprecation period. The result is clamped to 5-100 and banded Low, Moderate, High or Critical.