SemVer Compliance Check

Semantic Versioning is a contract encoded in the version number MAJOR.MINOR.PATCH:

• PATCH (1.2.3 → 1.2.4) — bug fixes only; nothing you rely on changes.
• MINOR (1.2.3 → 1.3.0) — new functionality, fully backward compatible.
• MAJOR (1.2.3 → 2.0.0) — breaking changes; you must review before upgrading.

When a module honors this contract, composer update with a ^ constraint is safe. When it doesn't, a "patch" release can silently break your store.

We use semverdict, an open-source auditor built on Magento's official Semantic Version Checker engine. For the last 10 release pairs of each package it:

1. downloads both releases from Packagist and diffs their entire public code surface,
2. computes the version bump the changes actually required (patch, minor, or major),
3. compares it with the bump the author actually shipped.

Each release pair gets a verdict:

The compliance percentage is (OK + OVER + 0.x exempt) / (pairs − FAILED). A package "Follows SemVer" when no audited pair is a violation. Every new release is re-audited automatically.

Magento's own versioning policy only guarantees compatibility for classes and methods marked @api. By that standard, removing or changing any other public method would be "not a breaking change".

Developer reality disagrees. In Magento, every public method is an extension point: plugins can intercept any public method of almost any class, and preferences can rewrite whole classes — that is the platform's core customization mechanism, and real projects use it everywhere, far beyond the @api surface.

So when a module changes a public method signature in a patch release, real stores break — regardless of what the annotation says. That's why our audit applies semantic versioning to the whole public code surface, the standard that reflects how modules are actually consumed.