Release¶
Once you are confident that the release doesn't need any more changes:
-
Create a PGP-signed git tag for the version, e.g., for dangerzone
v0.1.0:Pushing the tag publishes the documentation for this version on docs.dangerzone.rocks and points the
latestalias (the site default) to it. Between releases, pushes tomainonly update thedevversion of the site. -
Create an archive of the Dangerzone source in
tar.gzformat:export VERSION=$(cat share/version.txt) git archive --format=tar.gz -o dangerzone-${VERSION:?}.tar.gz --prefix=dangerzone/ v${VERSION:?}(This is covered by our automated build steps)
-
Run container scan on the produced container images (some time may have passed since the artifacts were built)
-
Collect the assets in a single directory, calculate their SHA-256 hashes, and sign them. There is an
./dev_scripts/sign-assets.pyscript to automate this task. -
Upload all the assets to the draft release on GitHub.
-
Update the draft release to target the final git tag.
-
Send a PR to update the Dangerzone website to link to the new installers.
-
Send a PR that updates the Dangerzone version and the links to our installation instructions in
README.md.
📣 Publish the release!¶
To actually publish the release:
- Merge the PR(s) in the
packagesrepository. - Make the GitHub draft release public.
- Merge the PRs in
dangerzone.rocksanddangerzone. - Toot release announcement on our mastodon account https://social.freedom.press/@dangerzone
- Extend the
check_repos.ymlCI test for the newly added platforms, if necessary - Manually trigger the
check_repos.ymlCI test and ensure it passes.