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.
Cherry picking, using the -xs flags, automatically adds a cross reference, for example
commit bc21cf1f9ca25dd3efcbc9806cee4f6c1726a905 Author: Marcus Müller <email@example.com> Date: Sun Aug 15 18:54:10 2021 +0200 audio/jack: to_string is no longer part of boost:: NS, instead use std:: Signed-off-by: Marcus Müller <firstname.lastname@example.org> (cherry picked from commit 883315208853121a8dfa68ae9c2f74400acd5ac5) Signed-off-by: Jeff Long <email@example.com>
For other commits, add cross references to Git commits only, not to PRs. The git repo should stand on its own. At the very least, explain how a commit relates to any work on the master branch.
About 2-3 weeks before release. This is informal. Accept only critical or very low risk changes at this point.
Mention on the Development and General Chat channels on Matrix. At this point, the mailing list is more for communicating with users than with core developers, so announcements there would not be useful, and could result in solicitation of extra PRs exactly when we are not going to consider them.
Slow down changes
About 1 week before release.
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 v22.214.171.124-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?
Tagging is done against a git clone of
firstname.lastname@example.org:gnuradio/gnuradio.git. Recommend keeping this in a separate directory, to avoid inadvertent pushes directly to the gnuradio repo.
git checkout <branch_name> git tag -u email@example.com <tag_name> -m '<tag_name>' git tag -v <tag_name> git push origin <tag_name>
This will use the latest signing key associated with firstname.lastname@example.org.
- 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
- For 3.8, create variants with a -with-volk-X.Y.Z suffix
- Check out volk using
git submodule update --init
- Create tar.gz and zip files
- Volk versions
- Previous to 126.96.36.199, it was included in all releases
- 188.8.131.52 -with-volk variant includes v2.0.0
- 184.108.40.206 and later include both v2.0.0 and latest-stable variants
- Fedora requested we continue to include Volk for 3.8 to keep packaging consistent
- Check out volk using
Verify or create valid signing key
Download tar.gz 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 email@example.com 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.
Add articles to the news section on the wiki https://github.com/gnuradio/hugo-website#how-to-add-stuff-to-the-website
Distros and other packagers