The breaking-change baseline is the base branch, not a release

[Onwcan]

What the gate does today

Pull requests run:

buf breaking --against ".git#branch=origin/$BASE_REF"

This correctly answers whether the PR is compatible with the branch it is being merged into.

On a push to main, the check skips because there is no meaningful base-branch comparison to perform.

The evidence files are regenerated by CI using the same script, so committed evidence cannot silently become stale.

That part is working as intended.

What it does not cover

The current check answers:

"Is this PR compatible with the branch it is merging into?"

It does not answer:

"Is main still compatible with the version consumers are actually running?"

Those two questions can diverge.

Examples include:

• a PR based on stale main
• rewritten history
• a long sequence of individually compatible changes
• consumers still built against a release tag from months earlier

For a contracts repository, compatibility with the deployed or released baseline is the question consumers ultimately care about.

Acceptance criteria

• Begin tagging releases, for example v1.0.0.
• Establish the most recent release tag as an additional breaking-change baseline.
• Add a second buf breaking invocation comparing against that release.
• Run the release-baseline comparison on pull requests.
• Run it on pushes to main as well.
• Keep the existing base-branch comparison.
• Do not replace one comparison with the other.
• The base-branch comparison should continue catching the PR's own regression with a better error message.
• The release-tag comparison should catch cumulative compatibility drift.
• Extend scripts/demonstrate-gate.sh to demonstrate the release-tag comparison.
• Generate committed evidence for the release comparison in the same style as the existing gate.

Why both checks matter

The two checks answer different questions.

The base-branch comparison asks whether the current PR introduces a regression relative to its merge target.

The release-tag comparison asks whether the repository has drifted away from the contract that deployed consumers actually built against.

They are complementary, not redundant.