chore: cut specification releases with release-please

[aepfli]

Reopens #431, which could not be reopened after its branch moved. Same change, plus a second package. Base of the provider-conformance stack: #423 (assets) → #439 (Appendix F) → #425 (report schema) stack on this, but it stands on its own and can merge alone.

What

Sets up release-please to cut the specification's releases, replacing the manual tagging step.

Why

The vX.Y.Z tags are created by hand. That is easy to postpone — v0.9.0 went out in July and the commits since it are unreleased — and it assembles the changelog from whoever's memory is handy. release-please proposes the version and the notes as a pull request, and tags once that pull request is merged.

What does not change

	before	after
tag	v0.9.0	v0.9.1, v0.10.0, …
next version after a breaking change	minor, while < 1.0.0	unchanged
who decides a release goes out	a maintainer merging	a maintainer merging the release PR

include-component-in-tag: false keeps the bare vX.Y.Z shape rather than spec/vX.Y.Z, and .release-please-manifest.json starts at 0.9.0 so numbering continues rather than restarting. release-type: simple because the root package.json is private: true and carries no version of its own; simple tracks the version in version.txt, which is why that file is added here.

Scope: the specification package only

One package, ., tagged vX.Y.Z as it always has been.

The conformance assets under specification/assets/provider-tck need their own tags too — a Go consumer cannot name a version without one — but that configuration belongs beside the assets, so it is added in #423 along with the files it describes. This PR stays the general setup and can merge on its own.

What does change, and needs a decision

Release notes become generated from conventional commits. v0.9.0's notes were written by hand, including the ⚠️ This release contains breaking changes callout linking #280, #306 and #360. Anything beyond the commit subjects now has to be added to the release pull request before it is merged.

If the TSC would rather keep the old shape, changelog-sections can be tuned in a follow-up — the defaults are left here so the first release is easy to eyeball.

What to expect on merge

release-please runs on push to main and should open a release pull request proposing v0.9.1; the non-chore commits since v0.9.0 are #416, #419, #429 and #408, all fix: or docs:. Nothing is tagged until that pull request is merged, so the first run is reviewable before it has any effect.

The action configuration is the shape v5 actually reads: command and default-branch are not v5 inputs, target-branch is, and signoff is a configuration-file option rather than an action input — which matters because this repository enforces DCO on the bot's own commits.

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: ba00852a-5dd3-479a-90ca-9ef656c802fe

📥 Commits

Reviewing files that changed from the base of the PR and between e1eb080 and 30081d1.

📒 Files selected for processing (1)

• .github/workflows/release-please.yaml

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 15c5e4d7-716d-4395-914a-76588a90613c

📥 Commits

Reviewing files that changed from the base of the PR and between a508a34 and e1eb080.

📒 Files selected for processing (3)

• .github/workflows/release-please.yaml
• .release-please-manifest.json
• release-please-config.json

🚧 Files skipped from review as they are similar to previous changes (1)

• .release-please-manifest.json

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

Adds Release Please configuration for the repository root, sets its version to 0.9.0, and adds a GitHub Actions workflow that runs Release Please on pushes to main.

Changes

Release automation

Layer / File(s)	Summary
Root package release settings release-please-config.json, .release-please-manifest.json, version.txt	Configures Release Please for the root package and sets its version to 0.9.0.
Release workflow .github/workflows/release-please.yaml	Adds a workflow triggered by pushes to main. It grants write permissions for contents, issues, and pull requests, then invokes Release Please v5.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Sequence Diagram(s)

sequenceDiagram
  participant GitHub
  participant ReleasePleaseWorkflow as Release Please workflow
  participant ReleasePleaseAction as Release Please action
  GitHub->>ReleasePleaseWorkflow: Push to main
  ReleasePleaseWorkflow->>ReleasePleaseAction: Invoke action with GitHub token and main target

Loading

Merge Risk: ⚪ Minimal · up to e1eb0

The release configuration has no confirmed merge-blocking defect. The repository’s required-check settings remain unverified.

Security Architecture Review

Security architecture risk: 🔵 Low · up to e1eb0

The automation is limited to pushes to main and uses a repository token rather than a separate privileged credential. No concrete vulnerability was established, but repository write authority is newly delegated to an external action. Enforced merge approval and recovery from interrupted or concurrent releases remain unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The configured release target is the root package, but the token permissions are not restricted to its version files. Compromise of the invoked action could affect repository contents and tags, issues, and pull requests, subject to hosted repository policies.

Trust Boundaries and Controls

• inferred — External action code crosses into repository write authority through GITHUB_TOKEN. The main-only trigger avoids directly running this job for an unmerged pull request, but enforced maintainer approval and bot bypass restrictions depend on unavailable hosted settings.

Resilience and Maintainability Implications

• observed — Initial package and version identity are consistent across configuration, manifest, and version.txt. This rejects an initial version mismatch, but does not establish consistency after partially completed release operations.

Hardening Proposals

• proposed — Consider pinning the release action to a reviewed immutable commit and verifying hosted merge protections and interrupted-release recovery before relying on automated release authority.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the change: using Release Please to cut specification releases.
Description check	✅ Passed	The description explains how Release Please will replace manual tagging and outlines the release process and scope.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

_{Comment @coderabbitai help to get the list of available commands.}