Skip to content

Release v0.2.35 #1103

Description

@joelcapitao

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

    • git checkout -b release
    • Bump the version number in Cargo.toml. Usually you just want to bump the patch.
    • Run cargo build to ensure Cargo.lock would be updated
    • Commit changes git commit -a -m 'Release x.y.z'; include some useful brief changelog.
  • Prepare the release

    • Run ./ci/prepare-release.sh
  • 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:

    • git push --set-upstream origin release
    • open a web browser and create a PR for the branch above
    • make sure the resulting PR contains the commit
    • in the PR body, write a short changelog with relevant changes since last release
    • get the PR reviewed, approved and merged
  • publish the artifacts (tag and crate):

    • git fetch origin && git checkout ${RELEASE_COMMIT}
    • verify Cargo.toml has the expected version
    • git-evtag sign v${RELEASE_VER}
    • git push --tags origin v${RELEASE_VER}
    • Automated: crates-release.yml publishes to crates.io via trusted publishing
  • publish this release on GitHub:

    • find the new tag in the GitHub tag list, click the triple dots menu, and create a release for it
    • write a short changelog with git shortlog $last_tag.. (i.e. re-use the PR content). See previous releases for format, for example v0.2.25
    • upload target/${PROJECT}-${RELEASE_VER}-vendor.tar.zstd
    • record digests of local artifacts:
      • sha256sum target/package/${PROJECT}-${RELEASE_VER}.crate
      • sha256sum target/${PROJECT}-${RELEASE_VER}-vendor.tar.zstd
    • publish release
  • clean up:

    • git push origin :release
    • cargo clean
    • git checkout main
  • Fedora packaging:

    • update the rust-bootupd spec file in Fedora
      • bump the Version
      • remove any patches obsoleted by the new release
    • run spectool -g -S rust-bootupd.spec
    • run kinit your_fas_account@FEDORAPROJECT.ORG
    • run fedpkg new-sources <crate-name> <vendor-tarball-name>
    • PR the changes in Fedora
    • once the PR merges to rawhide, merge rawhide into the other relevant branches (e.g. f35) then push those, for example:
      git checkout rawhide
      git pull --ff-only
      git checkout f35
      git merge --ff-only rawhide
      git push origin f35
    • on each of those branches run fedpkg build
    • once the builds have finished, submit them to bodhi, filling in:
      • rust-bootupd for Packages
      • selecting the build(s) that just completed, except for the rawhide one (which gets submitted automatically)
      • writing brief release notes like "New upstream release; see release notes at link to GitHub release"
      • leave Update name blank
      • Type, Severity and Suggestion can be left as unspecified unless it is a security release. In that case select security with the appropriate severity.
      • Stable karma and Unstable karma can be set to 2 and -1, respectively.
    • submit a fast-track for FCOS testing-devel
    • submit a fast-track for FCOS next-devel if it is open
  • RHCOS packaging:

    • update the rust-bootupd spec file
      • bump the Version
      • switch the Release back to 1%{?dist}
      • remove any patches obsoleted by the new release
      • update changelog
    • run spectool -g -S rust-bootupd.spec
    • run kinit your_account@REDHAT.COM
    • run rhpkg new-sources <crate-name> <vendor-tarball-name>
    • PR the changes
    • get the PR reviewed and merge it
    • update your local repo and run rhpkg build

CentOS Stream 9 packaging:

  • to be written

Metadata

Metadata

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions