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:

  git tag -s v0.1.0
  git push origin v0.1.0
  

  Pushing the tag publishes the documentation for this version on docs.dangerzone.rocks and points the latest alias (the site default) to it. Between releases, pushes to main only update the dev version of the site.

• Create an archive of the Dangerzone source in tar.gz format:

  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)

• Ensure that https://cves.dangerzone.rocks does not report any serious vulnerabilities.

• Collect the assets in a single directory, calculate their SHA-256 hashes, and sign them. There is an ./dev_scripts/sign-assets.py script to automate this task.

  # Sign all the assets
  ./dev_scripts/sign-assets.py ~/release-assets/$VERSION/github --version $VERSION
  

• Upload all the assets to the draft release on GitHub.

  find ~/release-assets/$VERSION/github | xargs -n1 ./dev_scripts/upload-asset.py --token ~/token --draft
  

• Update the draft release to target the final git tag.

• Send a PR to update the Dangerzone website with the new release announcement.

📣 Publish the release!¶

To actually publish the release:

• Merge the PR(s) in the packages repository.
• Make the GitHub draft release public.
• Merge the PRs in dangerzone.rocks and dangerzone.
• Toot release announcement on our mastodon account https://social.freedom.press/@dangerzone
• Extend the check_repos.yml CI test for the newly added platforms, if necessary
• Manually trigger the check_repos.yml CI test and ensure it passes.