Stop the release version constants failing the API compatibility gate
Cutting v0.20.0 (#940) failed the required API Compatibility check with all 12 required contexts green. The entire finding:
- ./pkg/basecamp.DefaultUserAgent: value changed from "basecamp-sdk-go/0.19.0 (api:2026-09-02)" to "basecamp-sdk-go/0.20.0 (api:2026-09-02)"
- ./pkg/basecamp.Version: value changed from "0.19.0" to "0.20.0"
scripts/bump-version.sh writes const Version; DefaultUserAgent is "basecamp-sdk-go/" + Version + " (api:" + APIVersion + ")", so it follows by construction. Every release changes both, so every release PR fails this gate, and the printed remedy is to apply breaking and re-run.
Why this is worth changing rather than living with
apidiff is not wrong. It flags an exported constant's value change because a consumer can use one in a constant expression. For these two that's true and beside the point — a consumer pinning the literal is asserting "compiled against exactly 0.19.0", which no release can preserve. Changing is what the constant is for.
The argument for fixing it is the gate's own integrity. A required check that fails on every release trains "bump PR, slap the label on" as reflex, and it does so on the one PR where a real break is least likely to be noticed: the diff is machine-generated and reviewers skim it. breaking should mean a real break was looked at and accepted. It cannot mean that while it is also the routine cost of shipping.
What changed
The two lines are partitioned out of the verdict only. They are still printed, under their own heading, and the All API Changes report is untouched — nothing becomes invisible.
The exemption is deliberately narrow: only value changed, only those two symbols.
grep's exit 1 ("no lines matched") is an ordinary outcome for both partitions and must not abort under set -e; exit 2+ is a tool failure and must not be read as an empty partition, so it aborts loudly — the same distinction run_apidiff already draws a few lines above.
Verification
Ran the partition against the real #940 output and five neighbours:
| case | verdict |
|---|---|
| the two v0.20.0 version lines alone | not breaking |
those lines plus Client.GetProject: removed | BREAKING |
Version: removed | BREAKING |
Version: changed from untyped string to int | BREAKING |
APIVersion: value changed (a different constant) | BREAKING |
| clean 0-byte report | not breaking |
The third through fifth rows are the ones that matter: the exemption keys on the symbol and the kind of change, so it cannot swallow a removal, a retype, or any other constant.
actionlint clean; zizmor (same online audit CI runs) reports 0 findings.
Not addressed here
Removing breaking after a green run still leaves that run green — the existing comment says so, and closing it needs a label-event trigger. Unchanged by this.
Summary by cubic
Stops release version bumps from failing the API compatibility gate. The expected Version and derived DefaultUserAgent changes no longer count as breaking, while unrelated API changes still block the check.
Behavior
- Exempts
DefaultUserAgentonly when its old and new values exactly follow theVersionchange and retain the same API version. - Keeps removals, type changes, unrelated constant changes, and other breaking APIs in the verdict.
- Prints exempted lines under a separate heading without changing the full “All API Changes” report.