Conversation
There was a problem hiding this comment.
Pull request overview
Adds an RFC documenting a proposed standard release automation approach for OpenFGA SDKs (and related repos) using Release Please and a GitHub App-based workflow to generate release PRs, bump versions (including cross-language markers), and publish tags/releases in a consistent way.
Changes:
- Introduces an RFC describing a two-phase “Release PR → tag/publish” release model powered by Release Please.
- Specifies conventions for version bumping (
x-release-please-versionmarkers) and standardized GitHub-style changelogs. - Proposes enforcement of Conventional Commits via PR title validation and outlines migration/rollout steps.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
|
||
| A standardized, near-zero-touch release process where: | ||
|
|
||
| 1. A maintainer triggers the release workflow from the GitHub Actions UI. |
There was a problem hiding this comment.
Given that (I think) we're aiming to be as frictionless in release as possible, how come we're making it run on-demand rather than every push to main? Is it mostly to support the custom version bumps?
I feel like having the open PR would reduce some of the mental overhead of tracking what's in a releasable state and with what
There was a problem hiding this comment.
The auto generated PR can still be enabled with a small tweak in the workflow ( which could always do a auto bump or maybe using this config to always have a patch etc. ) But we also need to be vary about it making mistakes because of release-please not being able to always perfectly decide the right bump if it was previously a non-standard tag.
The manual gate will always work though. So might just be worth having an open PR ready in each repo 🤔
|
|
||
| - **Nightly builds:** Build `main` on every merge (or nightly) to provide users with a "latest" build for testing prior to an official release. | ||
|
|
||
| - **Publishing to GitHub Packages Registry (GPR):** Publish SDK artifacts to GPR in addition to the primary language registries (npm, PyPI, Maven Central, NuGet, pkg.go.dev). |
There was a problem hiding this comment.
I know we've started this so maybe hard to stop, but I'm curious why. Does anyone use it?
Description
RFC proposing the adoption of Release Please to automate the release process for all OpenFGA SDKs, CLI, and extensions.
What problem is being solved?
Releasing a new SDK version is currently a manual process — updating changelogs, bumping version constants, creating signed tags, and pushing them. This overhead discourages frequent releases and leads to large, batched shipments.
How is it being solved?
A
workflow_dispatch-triggered GitHub Actions workflow powered by Release Please. A maintainer selects a bump type from the UI, Release Please opens a Release PR with all version bumps and changelog updates, and merging the PR finalizes the release (tag + GitHub Release). Authentication uses a dedicated GitHub App for short-lived, least-privilege tokens.What changes are made to solve it?
This RFC covers the full design: workflow configuration,
x-release-please-versionmarkers for cross-language version bumping, changelog format standardization (GitHub format), Conventional Commits enforcement via PR title validation, GitHub App identity/signing, migration steps, and a phased rollout plan.Relevant issue: openfga/sdk-generator#679
References
Review Checklist
main