The public-API check currently flags any change to a kernel's public API, even when the change is purely additive (e.g. adding new layer versions / new functions without modifying existing signatures). It also doesn't take the build.toml version into account, so bumping the version doesn't clear the warning.
Proposed improvements to the check script:
- Detect whether the version in
build.toml was changed as part of the PR.
- Enforce that the version only ever increments (and validate it's a proper bump).
- Only run the public-API-diff check when the version was not bumped — if the version was bumped, the API change is expected and shouldn't be flagged.
- Consider allowing additive-only changes (new functions/layers, no changes to existing signatures) to pass without complaint, so we don't need a version bump for every new exposure.
Context: this came up while merging additive layer-version PRs (#949, #995, #996) where the API-change check fired even though no existing function signatures changed.
Requested by Sayak Paul - Slack thread - Agent trace
The public-API check currently flags any change to a kernel's public API, even when the change is purely additive (e.g. adding new layer versions / new functions without modifying existing signatures). It also doesn't take the
build.tomlversion into account, so bumping the version doesn't clear the warning.Proposed improvements to the check script:
build.tomlwas changed as part of the PR.Context: this came up while merging additive layer-version PRs (#949, #995, #996) where the API-change check fired even though no existing function signatures changed.
Requested by Sayak Paul - Slack thread - Agent trace