Release process
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.
In order to ease downstream packaging of Rust binaries, an archive of vendored dependencies is also provided (only relevant for offline builds).
crates.io publishing uses trusted publishing (OIDC, no API tokens) and triggers automatically on tag push (.github/workflows/crates-release.yml).
Requirements
This guide requires:
- A web browser (and network connectivity)
git
- GPG setup and personal key for signing
- git-evtag
cargo (suggested: latest stable toolchain from rustup)
cargo-release (suggested: cargo install -f cargo-release)
cargo vendor-filterer (suggested: cargo install -f cargo-vendor-filterer)
- Write access to this GitHub project
Release checklist
-
Prepare local branch+commit
-
Prepare the release
-
Validate that origin points to the canonical upstream repository and not your fork:
git remote show origin should not be github.com/$yourusername/$project but should
be under the organization ownership. The remote yourname should be for your fork.
-
open and merge a PR for this release:
-
publish the artifacts (tag and crate):
-
publish this release on GitHub:
-
clean up:
-
Fedora packaging:
-
RHCOS packaging:
CentOS Stream 9 packaging:
Release process
The release process follows the usual PR-and-review flow, allowing an external reviewer to have a final check before publishing.
In order to ease downstream packaging of Rust binaries, an archive of vendored dependencies is also provided (only relevant for offline builds).
crates.io publishing uses trusted publishing (OIDC, no API tokens) and triggers automatically on tag push (
.github/workflows/crates-release.yml).Requirements
This guide requires:
gitcargo(suggested: latest stable toolchain from rustup)cargo-release(suggested:cargo install -f cargo-release)cargo vendor-filterer(suggested:cargo install -f cargo-vendor-filterer)Release checklist
Prepare local branch+commit
git checkout -b releaseCargo.toml. Usually you just want to bump the patch.cargo buildto ensureCargo.lockwould be updatedgit commit -a -m 'Release x.y.z'; include some useful brief changelog.Prepare the release
./ci/prepare-release.shValidate that
originpoints to the canonical upstream repository and not your fork:git remote show originshould not begithub.com/$yourusername/$projectbut shouldbe under the organization ownership. The remote
yournameshould be for your fork.open and merge a PR for this release:
git push --set-upstream origin releasepublish the artifacts (tag and crate):
git fetch origin && git checkout ${RELEASE_COMMIT}Cargo.tomlhas the expected versiongit-evtag sign v${RELEASE_VER}git push --tags origin v${RELEASE_VER}crates-release.ymlpublishes to crates.io via trusted publishingpublish this release on GitHub:
git shortlog $last_tag..(i.e. re-use the PR content). See previous releases for format, for examplev0.2.25target/${PROJECT}-${RELEASE_VER}-vendor.tar.zstdsha256sum target/package/${PROJECT}-${RELEASE_VER}.cratesha256sum target/${PROJECT}-${RELEASE_VER}-vendor.tar.zstdclean up:
git push origin :releasecargo cleangit checkout mainFedora packaging:
rust-bootupdspec file in FedoraVersionspectool -g -S rust-bootupd.speckinit your_fas_account@FEDORAPROJECT.ORGfedpkg new-sources <crate-name> <vendor-tarball-name>fedpkg buildrust-bootupdforPackageslink to GitHub release"Update nameblankType,SeverityandSuggestioncan be left asunspecifiedunless it is a security release. In that case selectsecuritywith the appropriate severity.Stable karmaandUnstablekarma can be set to2and-1, respectively.RHCOS packaging:
rust-bootupdspec fileVersionReleaseback to1%{?dist}spectool -g -S rust-bootupd.speckinit your_account@REDHAT.COMrhpkg new-sources <crate-name> <vendor-tarball-name>rhpkg buildCentOS Stream 9 packaging: