From c35377e6aa7688f0cb655f051b18e74a00c466aa 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 | 71 +++++++++++++------------ 1 file changed, 38 insertions(+), 33 deletions(-) diff --git a/docs/development/release_management.rst b/docs/development/release_management.rst index fc42627db..a31395fdc 100644 --- a/docs/development/release_management.rst +++ b/docs/development/release_management.rst @@ -35,13 +35,19 @@ Pre-Release ----------- 1. Open a **Release SecureDrop ..** issue to track release-related activity. - Keep this issue updated as you proceed through the release process for - transparency. + 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. You can compare it with the + `Tails release calendar `_ if you're not sure. The + goal is to make sure we test against the lastest Tails release, including release candidates, + so that we can report 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 - and upgrade Tor following these steps: + SecureDrop release. Also check for any new release candidates so that we're aware of any + upcoming major bug fixes and communicate them to the team. You can find releases by checking the + `Tor blog `_. If there is a new + stable release, file an issue and upgrade Tor following these steps: a. Bump the version in `fetch-tor-packages `_. Once the PR is merged, the - 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. + `Tor apt repo `_. Once the PR is + merged, the packages will be resigned with our an FPF-managed test-only signing key, + replacing the Tor signature, and served from ``apt-test.freedom.press``. #. Create a release branch. @@ -83,10 +79,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 @@ -95,7 +93,7 @@ Pre-Release script, you will need to pass it the new version in the format ``..~rcN``:: - securedrop/bin/dev-shell ../update_version.sh ..~rcN + bin/dev-shell ../update_version.sh ..~rcN .. note:: A tilde is used in the version number passed to ``update_version.sh`` to match the format specified in the `Debian docs @@ -120,6 +118,9 @@ Pre-Release git push origin ..-rcN + #. Once the tag is pushed, notify the Localization Manager so that the localization team can get + started on translations. + #. Build Debian packages: a. Check out the tag for the release candidate. @@ -129,18 +130,17 @@ Pre-Release `_. #. Open a PR on `securedrop-dev-packages-lfs `_ that targets the `main` - branch. Changes merged to this branch will be published to ``apt-test.freedom.press`` + branch with the new deb packages. Do not include tarballs or any debs that would overwrite + existing debs. Changes merged to this branch will be published to ``apt-test.freedom.press`` within 15 minutes. - .. warning:: Only commit packages with an incremented version number: do not clobber existing - packages. That is, if there is already a deb called e.g. + .. warning:: Only commit deb packages with an incremented version number: do not clobber existing + packages. That is, if there is already a deb called e.g. ``ossec-agent-3.6.0-amd64.deb`` in ``main``, do not commit a new version of this deb. - .. note:: If the release contains other packages not created by - ``make build-debs``, such as Tor or kernel updates, make - sure that they also get pushed to - ``apt-test.freedom.press``. + .. note:: If the release contains other packages not created by ``make build-debs``, such as Tor + or kernel updates, make sure that they also get pushed to ``apt-test.freedom.press``. #. Write a test plan that focuses on the new functionality introduced in the release. Post for feedback and make changes based on suggestions from the community. Once it's ready, publish the @@ -176,9 +176,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;