This page is a work in progress.
Manual Release Process Notes
Documenting the steps taken todo a release manually, in hopes that it can be automated.
Slow down changes
Around one week unless problems are found.
Sync/deconflict with other branches
Version change for release
Date and version
- Change CMakeLists.txt to MAJOR.API.ABI.PATCH. If a release candidate, PATCH `-rc0`format to help with sort order. For final version, PATCH is `0`
- Create PR with this change, title formatted like "Release v126.96.36.199-rc1"
- Merge release PR
- Sync local checkout for later comparison step
Version change for continuation
Skip if this is a RC version. The branch will stay linear until the final version is released.
Change CMakeLists.txt to MAJOR.API.ABI.git
Unreleased version number?
- In Github, go to code, branch, and then release list (or tags, then hit releases)
- Draft a new release
- Select branch and enter release version from commit as a tag
- Title same as commit: "Release v..."
- Github creates a tar.gz and a zip
- Download these files immediately
Verify or create valid signing key
Download tarball and zip
If not done in release step
- Unpack each archive
- Diff against existing git checkout to verify, e.g., with meld. Expect minor differences due to git ignored files (e.g., `__pycache__`, `.vscode`)
- Keep the tar and zip files locally for a little while in case something comes up
- Create detacted signatures: `gpg --detach-sign --armor -u firstname.lastname@example.org filename`
- Verify signatures: `gpg --verify filename.asc`
- Keep the signatures locally for a little while in case something comes up
Upload signatures and public key
- On Github release page, edit release
- Click "attach binaries" or drag/drop files
- Note that the signing key should also be somewhere else where people can verify it
Takes care of itself.
Point to releases page, changelog page, ask for problem reports via email or issue tracker.
Distros and other packagers