The release branch is the only production publishing branch. Normal releases and hotfixes both enter production through a pull request targeting release. Merging into master never publishes a production image.

Normal release

Complete any pending release to master backmerge.
Create release/X.Y.Z from the desired commit on master.
Update CAPROVER_VERSION and RELEASE_FRONTEND_COMMIT in release/release.conf.
Add a matching ## [X.Y.Z] section to CHANGELOG.md.
Open Release vX.Y.Z targeting release.
Merge the PR after its checks pass.

The resulting push to release publishes the production image and creates the draft GitHub release. After publication succeeds, automation opens a release to master backmerge PR and enables auto-merge when possible.

The release branch captures the state of master when release/X.Y.Z was created. Later commits to master are left for the next release.

Hotfix

Create hotfix/X.Y.Z from the current release branch.
Apply the fix.
Update release/release.conf and CHANGELOG.md as described above.
Open Hotfix vX.Y.Z targeting release.
Merge the PR after its checks pass.

This publishes the previous production code plus the hotfix, without including unreleased work from master. The automated backmerge carries the fix and release metadata into future releases.

Required repository settings

Protect release from direct pushes and require pull requests, approvals, and the release validation checks. Allow GitHub Actions to create and approve pull requests so the publishing workflow can open and auto-merge backmerge PRs.

GitHub does not start pull_request workflows for a PR created with the built-in GITHUB_TOKEN. The backmerge script explicitly dispatches the build, format, and lint workflows against the release commit before enabling auto-merge. Repository rules remain responsible for waiting for those checks.

The scripts in this directory contain the release logic. The workflows under .github/workflows provide triggers, permissions, and runner setup.