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).
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)
- A verified account on crates.io
- Write access to this GitHub project
- Upload access to this project on GitHub, crates.io
- Membership in the Fedora CoreOS Crates Owners group
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).
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}cargo publishpublish 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.gzsha256sum target/package/${PROJECT}-${RELEASE_VER}.cratesha256sum target/${PROJECT}-${RELEASE_VER}-vendor.tar.gzclean 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: