Releases
You want a build in front of its audience. A release moves one existing build into one channel and records everything that follows. Promotion never rebuilds.
Promoting
POST /api/projects/{id}/releasesThe body names buildId, channel, sourceChannel and browsers. One promote run dispatches per browser, correlated by a minted dispatch id. Name nothing and the promotion defaults preview to preview.
The promotion is checked before it runs. Every refusal it can return is in Promote gates.
Cutting a version
POST /api/projects/{id}/releases/cutlevel is patch, minor or major. Only the project owner can cut. The cut bumps the manifest version in your source repository and opens a release PR.
A cut can be armed. An armed cut auto-releases: the moment the matching build goes green, it promotes. Arming works from the release PR body, so merging the PR ships.
The event log and rollback
Each channel keeps an event log of what entered it and when. Rollback resolves the previous build for the channel and promotes it again. A channel with no previous build refuses with 409 NO_ROLLBACK_TARGET.
In event and rollback URLs, the release id is the channel name. To read stable's events or roll stable back, use stable as the id.
Rolling back a channel does not roll back a store. A build already published stays published until a new submission replaces it. Roll the channel back, then submit again from it.
GitHub tags
Tagging a GitHub release for each promotion is per-project opt-in, off by default.
When it fails
409 NO_ROLLBACK_TARGET. The channel holds its first build; there is nothing behind it. Promote the build you want by id withPOST /api/projects/{id}/releasesinstead.- Promotion refused with a code. See Promote gates for every code and its fix.
- Cut refused. Cutting is owner only. Ask the project owner to cut, or to transfer ownership.
- Armed cut never shipped. It fires only when the matching build goes green. Check
GET /api/projects/{id}/builds/live-statusand the build logs for the failure.
