chore: cut specification releases with release-please by aepfli · Pull Request #440 · open-feature/spec

aepfli · 2026-10-02T08:47:11Z

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.

The specification's vX.Y.Z tags are created by hand today. That is a step easy to postpone -- v0.9.0 went out in July and the four commits since it are unreleased -- and a step where the changelog is assembled by whoever remembers to. release-please proposes the version and the notes as a pull request instead, and tags when it is merged. Nothing about the tag shape changes. include-component-in-tag is false, so releases stay vX.Y.Z rather than becoming spec/vX.Y.Z, and the manifest starts at 0.9.0 so numbering continues from the current release instead of restarting. bump-minor-pre-major keeps the pre-1.0 convention the specification already follows, where a breaking change bumps the minor. release-type is simple because the root package.json is private and carries no version of its own; simple tracks the version in version.txt. One consequence worth naming in review: release notes become generated from conventional commits, where v0.9.0's were written by hand. Anything that needs saying beyond the commit subjects -- the breaking-change callout at the top of v0.9.0, say -- now has to be added to the release pull request before it is merged. This is deliberately the whole of it: a single package, no tag separator and no component tagging, because there is nothing else in the repository to release yet. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

Three inputs in the workflow were written against the v3 action and are silently ignored by v5, which is worse than an error because the workflow still runs and appears to work: - command: manifest is not an input. v5 is manifest-mode whenever a config file is present, which it is. - default-branch was renamed target-branch. - signoff moved to the configuration file, as $.signoff. The last one matters here. This repository enforces DCO, so an ignored signoff means release-please's own commits arrive without a Signed-off-by line and its release pull request fails the DCO check -- the failure the option was added to prevent. It is now a key in release-please-config.json, where v5 reads it. Also adds issues: write, which the action's own recommended permissions block carries; release-please labels its pull requests, and labelling goes through the issues API. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

coderabbitai · 2026-10-02T08:47:24Z

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

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.}

A second release-please package, so the assets added here are tagged specification/assets/provider-tck/vX.Y.Z. That is the shape `go get` needs: without a tag a Go consumer can only name a pseudo-version, which is what the four conformance implementations have had to do while this branch was unmerged. The specification package excludes this path, so an asset-only change no longer cuts a specification release, and separate-pull-requests keeps the two from sharing one release pull request. The general release-please setup is #440, which this stacks on; this commit adds only the part that describes the assets beside them. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

Signed-off-by: Todd Baert <todd.baert@dynatrace.com>

A second release-please package, so the assets added here are tagged specification/assets/provider-tck/vX.Y.Z. That is the shape `go get` needs: without a tag a Go consumer can only name a pseudo-version, which is what the four conformance implementations have had to do while this branch was unmerged. The specification package excludes this path, so an asset-only change no longer cuts a specification release, and separate-pull-requests keeps the two from sharing one release pull request. The general release-please setup is #440, which this stacks on; this commit adds only the part that describes the assets beside them. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

open-feature/spec#440 landed the general release-please setup on main, so #423 was replayed onto it without those commits and its tip moved. Embedded artifacts are byte-identical, so the digest is unchanged. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

open-feature/spec#440 landed the general release-please setup on main, so #423 was replayed onto it without those commits and its tip moved. Artifacts are byte-identical, so PINNED_DIGEST is unchanged. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>