The Release Manager is responsible for shepherding the release process to successful completion. This document describes their responsibilities. Some items must be done by people that have special privileges to do specific tasks (e.g. privileges to access the production apt server), but even if the Release Manager does not have those privileges, they should coordinate with the person that does to make sure the task is completed.
- Open a Release SecureDrop 1.x.y issue to track release-related activity. Keep this issue updated as you proceed through the release process for transparency.
- Check if there is a new stable release of Tor that can be QAed and released as part of the SecureDrop release. If so, file an issue.
- Check if a release candidate for the Tails release is prepared. If so, request people participating in QA to use the latest release candidate.
- Prepare a changelog describing the changes in the release.
- Ensure that a pre-release announcement is prepared and shared with the community for feedback. Once the announcement is ready, coordinate with other team members to send them to current administrators, post on the SecureDrop blog, and tweet out a link.
- For a regular release for version 1.x.0, branch off
git checkout develop git checkout -b release/1.x
For new branches, please ask a
administrator to enable branch protection on the release branch. We want to
require CI to be passing as well as at least one approving review prior to
merging into the release branch.
- Prepare each release candidate where
rcNis the Nth release candidate using this script:
securedrop/bin/dev-shell ../update_version.sh 1.x.y~rcN
If you would like to sign the release commit, you will need to do so manually:
- Create a new signed commit and verify the signature:
git reset HEAD~1 git commit -aS git log --show-signature
- Ensure the new commit is signed, take note of the commit hash.
1.x.y-rcN.tagand replace the commit hash with the new (signed) commit hash.
- Delete the old tag and create a new one based on the tag file edited above:
git tag -d 1.x.y-rcN git mktag < 1.x.y-rcN.tag > .git/refs/tags/1.x.y-rcN
Push the branch and tags:
1.x.y~rc1, push the
- For subsequent release candidates and the final release version, issue
a PR with changelog and version changes into the
release/1.x.ybranch, and push the signed tag once the PR is merged.
Build Debian packages and place them on
apt-test.freedom.press. This is currently done by making a PR into a git-lfs repo here. Only commit packages with an incremented version number: do not clobber existing packages. That is, if there is already a deb called e.g.
master, do not commit a new version of this deb. Changes merged to
masterin this repo will be published within 15 minutes.
If the release contains other packages not created by
such as Tor or kernel updates, make sure that they also get pushed to
- Build logs from the above debian package builds should be saved and published according to the build log guidelines.
- 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.
- Encourage QA participants to QA the release on production VMs and hardware. They should post their QA reports in the release issue such that it is clear what was and what was not tested. It is the responsibility of the release manager to ensure that sufficient QA is done on the release candidate prior to final release.
- Triage bugs as they are reported, if a bug is important to fix and does not receive attention, you should fix the bug yourself or find someone who agrees to work on a fix.
- Backport release QA fixes merged into
developinto the release branch using
git cherry-pick -x <commit>to clearly indicate where the commit originated from.
- At your discretion - for example when a significant fix is merged - prepare additional release candidates and have fresh Debian packages prepared for testing.
- For a regular release, the string freeze will be declared by the translation administrator one week prior to the release. After this is done, ensure that no changes involving string changes are backported into the release branch.
- Ensure that a draft of the release notes are prepared and shared with the community for feedback.
- If this is a regular release, work with the translation administrator responsible for this release cycle to review and merge the final translations and screenshots (if necessary) they prepare. Refer to the i18n documentation for more information about the i18n release process. Note that you must manually inspect each line in the diff to ensure no malicious content is introduced.
- Prepare the final release commit and tag. Do not push the tag file.
- Step through the signing ceremony for the tag file. If you do not have permissions to do so, coordinate with someone that does.
- Once the tag is signed, append the detached signature to the unsigned tag:
cat 1.x.y.tag.sig >> 1.x.y.tag
- Delete the original unsigned tag:
git tag -d 1.x.y
- Make the signed tag:
git mktag < 1.x.y.tag > .git/refs/tags/1.x.y
- Verify the signed tag:
git tag -v 1.x.y
- Push the signed tag:
git push origin 1.x.y
Ensure there are no local changes (whether tracked, untracked or git ignored) prior to building the debs. If you did not freshly clone the repository, you can use git clean:
Dry run (it will list the files/folders that will be deleted):
git clean -ndfx
Actually delete the files:
git clean -dfx
Build Debian packages. People building Debian packages should verify and build off the signed tag. Build logs should be saved and published according to the build log guidelines.
Step through the signing ceremony for the
Releasefile(s) (there may be multiple if Tor is also updated along with the SecureDrop release).
Coordinate with the Infrastructure team to put signed Debian packages on
- If the release includes a Tor update, make sure to include the new Tor Debian packages.
- If the release includes a kernel update, make sure to add the corresponding grsecurity-patched kernel packages, including both
linux-firmware-image-*packages as appropriate.
- Coordinate with one or more team members to confirm a successful clean install
in production VMs using the packages on
- Ask Infrastructure to perform the DNS cutover to switch
apt.freedom.press. Once complete, the release is live.
- Make sure that the default branch of documentation is being built off the tip of the release branch. Building from the branch instead of a given tag enables us to more easily add documentation changes after release. You should:
- Log into readthedocs.
- Navigate to Projects → securedrop → Versions → Inactive Versions → release/branch → Edit.
- Mark the branch as Active by checking the box and save your changes. This will kick off a new docs build.
- Once the documentation has built, it will appear in the version selector at the bottom of the column of the.
- Now set this new release as default by navigating to Admin → Advanced Settings → Global Settings → Default Version.
release/branchfrom the dropdown menu and save the changes.
- Verify that docs.securedrop.org redirects users to the documentation built from the release branch.
- Create a release on GitHub with a brief summary of the changes in this release.
- Make sure that release notes are written and posted on the SecureDrop blog.
- Make sure that the release is announced from the SecureDrop Twitter account.
- Make sure that members of the support portal are notified about the release.
After the release, carefully monitor the FPF support portal (or ask those that have access to monitor) and SecureDrop community support forum for any issues that users are having.
Finally, in a PR back to develop, cherry-pick the release commits (thus ensuring a consistent changelog in the future) and bump the version numbers in preparation for the next release (this is required for the upgrade testing scenario).