From c07791cfa62f6e1bd11c093be77b81a18d3562c5 Mon Sep 17 00:00:00 2001 From: Allie Crevier Date: Mon, 11 Jan 2021 10:05:38 -0800 Subject: [PATCH] clarify pre-release instuctions --- docs/development/release_management.rst | 36 +++++++++++++------------ 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/docs/development/release_management.rst b/docs/development/release_management.rst index fc42627db..7be276820 100644 --- a/docs/development/release_management.rst +++ b/docs/development/release_management.rst @@ -38,6 +38,11 @@ Pre-Release Keep this issue updated as you proceed through the release process for transparency. +#. Copy a link of the latest release or release candidate from the `Tails apt repo + `_ and include it in the issue. This is to ensure QA tests + against the latest release/ release candidate and can report any release candidate bugs early to + Tails. + #. Check if there is a new stable release of Tor that can be QAed and released as part of the SecureDrop release. You can find stable releases by checking the `Tor blog `_. If we can upgrade, file an issue @@ -58,16 +63,6 @@ Pre-Release packages will be resigned with our an FPF-managed test-only signing key, replacing the Tor signature, and served from ``apt-test.freedom.press``. -#. Check if a new release or release candidate for Tails has been added to the `Tails apt repo - `_. If so, request - people participating in QA to use the latest release candidate. - -#. Work with the Communications Manager assigned for the release to prepare a pre-release - announcement that will be shared on the support.freedom.press support portal, securedrop.org - website, and Twitter. Wait until the day of the release before including an announcmement for a - SecureDrop security update. For a point release, you may be able to skip the pre-release - announcement depending on how small the point release is. - #. Create a release branch. For a regular release, create a release branch off of ``develop``:: @@ -83,10 +78,12 @@ Pre-Release #. For each release candidate, update the version and changelog. - a. Collect a list of important changes from the `SecureDrop milestones - `_ for the release, including - GitHub issues or PR numbers for each change. You will add these changes to the changelog in - the next step. + a. Collect a list of changes since the last release. For example, if the last release was version + 1.6.0, you can view changes in Github by running: + `https://github.com/freedomofpress/securedrop/compare/release/1.6.0...develop`. Also check + `SecureDrop milestones `_ to make + sure all milestone changes there are included. Include GitHub PR numbers for each change. + You will add these changes to the changelog in the next step. #. Run ``update_version.sh`` in the dev shell to update the version and changelog. The script will open both the main repository changelog (``changelog.md``) and the one used for Debian @@ -176,9 +173,14 @@ Pre-Release is done, ensure that no changes involving string changes are backported into the release branch. - * Work with the Communications Manager to ensure that a draft of the release - notes are prepared and shared for review, and that a draft PR is prepared - into the ``securedrop-docs`` repository which: + * Work with the Communications Manager assigned for the release to prepare a pre-release + announcement that will be shared on the support.freedom.press support portal, securedrop.org + website, and Twitter. Wait until the day of the release before including an announcmement for a + SecureDrop security update. For a point release, you may be able to skip the pre-release + announcement depending on how small the point release is. + + Make sure a draft of the release notes are prepared and shared for review, and that a draft PR + is prepared into the ``securedrop-docs`` repository which: - bumps the SecureDrop version of the documentation using the ``update_version.sh`` script in that repository;