Skip to content

Latest commit

 

History

History
29 lines (28 loc) · 1.74 KB

MAINTENANCE.md

File metadata and controls

29 lines (28 loc) · 1.74 KB

Creating a release

  • Confirm top-level docs have been updated for any changes since the last release.
  • Update man page if required:
    • cargo xtask man
      • N.B. This isn't automated in CI to save repeating work across multiple builds.
    • Commit it
  • Create PR:
    • (Optional) release-plz update to preview updates to the changelog and version
    • release-plz release-pr --git-token $GITHUB_QCP_TOKEN
    • if this token has expired, you'll need to generate a fresh one; walk back through the release-plz setup steps
  • Review changelog, edit if necessary.
  • Merge the PR (rebase strategy preferred)
  • Delete the PR branch
  • git fetch && git merge --ff-only
  • Finalise the release:
    • release-plz release --git-token $GITHUB_QCP_TOKEN
    • Check the new Github release page; update notes as necessary. Publication of the github release triggers the artifact builds.
  • Merge dev into main, or whatever suits the current branching strategy
    • main is set to require linear history and is a protected branch. Do not rebase-merge!
      • Create a PR for dev into main in the usual way.
      • Locally make the fast-forward merge
      • Push to main. Even though it is protected the PR is allowed.
  • Check the docs built, follow up on the release workflow, etc.
  • Update the build support files.
    • For Nix packages:
      • Update tagged release version in nix/default.nix
      • Pre-compute the release hash (v0.3.0 is the release in this example) and replace the fetchFromGithub.hash value to the output SRI: nix hash to-sri --type sha256 "$(nix-prefetch-url --unpack 'https://github.com/crazyscot/qcp/archive/v0.3.0.tar.gz')".
      • Run a test build with previous hashes or lib.fakeHash set for cargoHash and place the expected hash in place.