Skip to content

Pre-release

Here is a list of tasks that should be done before issuing the release. They can run from the developer's laptop and are not tied to any build environment.

  • Create a new issue named QA and Release for version \<VERSION>, to track the general progress. You can generate its content with the poetry run ./dev_scripts/generate-release-tasks.py command.
  • Add new Linux platforms and remove obsolete ones
  • Bump the Python dependencies using poetry lock --regenerate
  • Bump the GitHub asset dependencies using poetry run mazette lock
  • Bump the version of the dangerzone-image repo, in case of code changes.
  • Check for new WiX releases and update it if needed (see #1200)
  • Update version in pyproject.toml
  • Update share/version.txt
  • Update share/version_insecure_converter.txt, if necessary
  • Update the "Version" field in install/linux/dangerzone.spec
  • (optional) Bump image version from v1 to v2, if the API has changed.
  • Bump the Debian version by adding a new changelog entry in debian/changelog
  • Run make docs-cog to refresh the generated parts of the docs, including the download links in docs/how-to/install/index.md (the links will start working once the release assets are published)
  • Update screenshot in README.md, if necessary
  • CHANGELOG.md should be updated to include a list of all major changes since the last release
  • A draft release should be created. Copy the release notes text from the release notes templates
  • Send the release notes to editorial for review
  • Tag the tip of the main branch as v<version>-rc1. E.g. git tag -s v0.9.1-rc1.

Add new Linux platforms and remove obsolete ones

Currently supported Linux OSes are Debian, Ubuntu and Fedora (we treat Qubes OS as a special case of Fedora, release-wise). For each of these platforms, check if a new version has been added, or if an existing one is now EOL (https://endoflife.date/ is handy for this purpose).

In case of a new version (beta, RC, or official release):

  1. Add it in our CI workflows, to test if that version works.
    • See .circleci/config.yml and .github/workflows/ci.yml, as well as dev_scripts/env.py.
  2. Test this version locally, following the QA checklist. Focus on the GUI part, since the basic functionality is already tested by our CI workflows.
  3. Add the new version in our docs/how-to/install/index.md and docs/reference/supported-platforms.md documents, and drop a line in our CHANGELOG.md.
  4. If that version is a new stable release, update the docs/how-to/release/ and docs/how-to/contribute/build-from-source.md files where necessary.
  5. Send a PR with the above changes.

In case of the removal of a version:

  1. Remove any mention of this version from our repo.
    • Consult the previous paragraph, but also grep your way around.
  2. Add a notice in our CHANGELOG.md about the version removal.