Skip to content

docs: Explain how to create and check release branches #656

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
saulecabrera merged 1 commit into from
Oct 15, 2026
Merged

docs: Explain how to create and check release branches #656

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 19 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,24 @@ To release a patch for an older version, e.g. `48.0.2` when `main` is on 49:

1. If `release-<major>` (e.g. `release-48`) doesn't exist, run the
[Release branch] workflow manually with the major version. It creates the
branch from the latest `v<major>.*` tag.
branch from the latest `v<major>.*` tag. Run it from the Actions tab, or
with the GitHub CLI:
```
gh workflow run release-branch.yml --ref main -f major=<MAJOR_VERSION>
```
1. Check that the branch still builds, since the toolchains and workflows may
have changed since its last release. Run the CI workflow on the branch, and
the [Release] workflow from `main` with the branch as `ref`. From the Actions
tab, pick the release branch in "Use workflow from" for CI, and `main` with
the release branch in the `ref` field for Release. With the GitHub CLI:
```
gh workflow run ci.yml --ref release-<MAJOR_VERSION>
gh workflow run release.yml --ref main -f ref=release-<MAJOR_VERSION>
```
The Release run is a dry run: it builds and smoke-tests the gems without
publishing them. Always run it from `main`; run from a tag, the workflow
releases that tag. Fix any failures through pull requests into the
release branch.
1. Merge the patches to release into `release-<major>` through pull requests.
1. Run the [Release bump] workflow manually with branch `release-<major>`.
1. Open both pull requests from the links in the workflow run's summary:
Expand All @@ -87,3 +104,4 @@ To release a patch for an older version, e.g. `48.0.2` when `main` is on 49:
[Release branch]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release-branch.yml
[Release bump]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release-bump.yml
[Release tag]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release-tag.yml
[Release]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release.yml
4 changes: 3 additions & 1 deletion docs/security-vulnerability-runbook.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,9 @@ supported.
`ref`. This is a dry run: it builds and smoke-tests the gems but never
publishes.

Fix any failures through pull requests into the release branch.
See [From a release branch](../CONTRIBUTING.md#from-a-release-branch) for
the commands. Fix any failures through pull requests into the release
branch.

1. **Collaborate on a fix in private.** Create the temporary private fork
attached to the advisory and develop the fix there as a pull request
Expand Down
Loading