deb-bootupd/.github/ISSUE_TEMPLATE/release-checklist.md
robojerk aaf662d5b1
Some checks failed
Cross build / Build on ppc64le (push) Failing after 1m8s
Cross build / Build on s390x (push) Failing after 2s
Restructure project layout for better CI/CD integration
- Flattened nested bootupd/bootupd/ structure to root level
- Moved all core project files to root directory
- Added proper Debian packaging structure (debian/ directory)
- Created build scripts and CI configuration
- Improved project organization for CI/CD tools
- All Rust source, tests, and configuration now at root level
- Added GitHub Actions workflow for automated testing
- Maintained all original functionality while improving structure
2025-08-09 23:11:42 -07:00

5.4 KiB
Executable file

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

    • 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}
    • cargo publish
  • 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.gz
    • record digests of local artifacts:
      • sha256sum target/package/${PROJECT}-${RELEASE_VER}.crate
      • sha256sum target/${PROJECT}-${RELEASE_VER}-vendor.tar.gz
    • 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