Release Process

Release Please prepares version and changelog PRs against dev. Release metadata is validated and promoted with application code, preserving identical commits on all four branches.

Normal release

Merge reviewed feature and dependency changes into dev.
Review the Release Please PR titled chore(release): release X.Y.Z against dev.
Confirm synchronized workspace versions and merge after checks pass.
Run Promote validated commit from dev with target prod.
Confirm production approval at dispatch; the workflow advances prod only after checks pass.
Confirm the production deployment and GitHub Release.

The dev workflow updates the release PR without publishing a release. The prod workflow publishes without opening another PR, and only while dev and prod match the run SHA. If dev has advanced, publication waits for a later matching run. There is no prod-only version commit or reverse-sync PR.

Authentication

Add a fine-grained RELEASE_PLEASE_TOKEN Actions secret with repository Contents, Pull requests, and Issues read/write access. The workflow falls back to GITHUB_TOKEN, but PRs created with that token do not trigger other Actions, so the dedicated token is required before enabling the production Ruleset. The bootstrap SHA in release-please-config.json prevents historical commits from being pulled into the first release proposal. Remove or update it only after reviewing Release Please’s documented bootstrap behavior.

Commit examples

feat(booking): add wait-list capacity
fix(auth): retain the return URL after sign-in
docs(platform): document the release process

Breaking changes use ! and a BREAKING CHANGE: footer. See the official Release Please Action and manifest configuration.

Getting started

System design

Standards

Application surface

Platform

Quality & security

Operations

Delivery workflow

Normal release

Authentication

Commit examples

​Normal release

​Authentication

​Commit examples

Normal release

Authentication

Commit examples