Motivation

oasdiff detects the severity of changes between two specs. A common governance need is to enforce that info.version was bumped to match that severity: a breaking change requires a major bump, and any functional change requires some bump. Today people hand-roll this in CI by combining the action's pass/fail outcome with shell version math (see oasdiff/oasdiff-action#154). oasdiff is the natural place to do it, because it already knows both halves: the change severity, and info.version on each side.

Proposal

Add an opt-in check that compares the detected change severity against the info.version delta and reports when the bump is insufficient. As a checker rule it flows through everything that already exists, --fail-on, the changelog / breaking output, --err-ignore, and the action wrappers, with no new surface.

Design it as a versioning policy rather than a single hard-coded rule, so it can grow beyond the first cases.

v1 scope (start simple)

• A breaking change is present but the major version did not increase.
• The spec changed but info.version is unchanged.

Open design questions (input welcome)

• Non-semver info.version (dates, v1, calendar versions, etc.): skip gracefully rather than error. This is part of why it should be opt-in.
• Strict semver, including the pre-1.0 rule where a breaking change bumps the minor while still on 0.x?
• Later: "an additive change requires at least a minor bump". This mapping is fuzzier (oasdiff's levels don't cleanly separate functional additions from cosmetic ones), so it likely comes after the first two rules.
• Configurable policy (which severities require which bump) vs a fixed default.

Notes

• Requires reading info.version from both specs; the checker does not use it today.
• Opt-in via --include-checks.

Originating request: oasdiff/oasdiff-action#154