Found this in your own spec history
I ran a structural diff on spec/api.json between v2.3.0 and v26.2.0 and it surfaced 5 breaking changes:
pagination and paginationHeaders schemas removed from componentsMaxItems and DefaultItems parameters removed from GET /admin/trust/grants/jwt-bearer/issuersdevice_authorization_endpoint became a required field in oidcConfiguration
The major bump from v2 to v25 covered all of them, so nothing is broken today. The reason I'm flagging it: the required_field_added on oidcConfiguration is the kind of change that a reviewer can't easily eyeball from a PR diff. If a future change like that one slipped into a non-major release, older OIDC discovery consumers that don't supply the field would silently break, and the spec change in the PR wouldn't make the impact obvious.
Proposal
Add a CI step that runs the same kind of diff on every PR and posts a comment when it sees a breaking change. Advisory-only at first; you can decide later whether to fail the build or to require a release-note/breaking label.
This pattern was merged into goharbor/harbor's CI in goharbor/harbor#23089 last week, if a reference is useful.
Would an advisory-only PR along these lines be welcome? Happy to keep it limited to the diff + comment, with no other scope.
Found this in your own spec history
I ran a structural diff on
spec/api.jsonbetween v2.3.0 and v26.2.0 and it surfaced 5 breaking changes:paginationandpaginationHeadersschemas removed from componentsMaxItemsandDefaultItemsparameters removed fromGET /admin/trust/grants/jwt-bearer/issuersdevice_authorization_endpointbecame a required field inoidcConfigurationThe major bump from v2 to v25 covered all of them, so nothing is broken today. The reason I'm flagging it: the
required_field_addedonoidcConfigurationis the kind of change that a reviewer can't easily eyeball from a PR diff. If a future change like that one slipped into a non-major release, older OIDC discovery consumers that don't supply the field would silently break, and the spec change in the PR wouldn't make the impact obvious.Proposal
Add a CI step that runs the same kind of diff on every PR and posts a comment when it sees a breaking change. Advisory-only at first; you can decide later whether to fail the build or to require a
release-note/breakinglabel.This pattern was merged into goharbor/harbor's CI in goharbor/harbor#23089 last week, if a reference is useful.
Would an advisory-only PR along these lines be welcome? Happy to keep it limited to the diff + comment, with no other scope.