-
David Goulet authored
Signed-off-by:
David Goulet <dgoulet@torproject.org>
David Goulet authoredSigned-off-by:
David Goulet <dgoulet@torproject.org>
How to Release Tor
Here are the steps that the maintainer should take when putting out a new Tor release. It is split in 3 stages and coupled with our Tor CI Release pipeline.
Before we begin, first rule is to make sure:
- Our CIs (*nix and Windows) pass for each version to release
- Coverity has no new alerts
0. Security Release
To start with, if you are doing a security release, this must be done few days prior to the release:
- If this is going to be an important security release, give the packagers
advance warning, via
tor-packagers@lists.torproject.org
.
1. Preliminaries
The following must be done 2 days at the very least prior to the release:
-
Add the version(s) in the dirauth-conf git repository as the RecommendedVersion and RequiredVersion so they can be approved by the authorities and be in the consensus before the release.
-
Send a pre-release announcement to
tor-project@lists.torproject.org
in order to inform every teams in Tor of the upcoming release. This is so we can avoid creating release surprises and sync with other teams. -
Ask the network-team to review the
changes/
files in all versions we are about to release. This step is encouraged but not mandatory.
2. Tarballs
To build the tarballs to release, we need to launch the CI release pipeline:
https://gitlab.torproject.org/tpo/core/tor-ci-release
The versions.yml
needs to be modified with the Tor versions you want to
release. Once done, git commit and push to trigger the release pipeline.
The first two stages (Preliminary and Patches) will be run automatically. The Build stage needs to be triggered manually once all generated patches have been merged upstream.
-
Download the generated patches from the
Patches
stage.Apply these patches to the
main
orrelease
branch as appropriate. (Version bumps apply tomaint
; anything touching the changelog should apply only tomain
orrelease
.)When updating the version, it will be on
maint
branches and so to merge-forward, usegit merge -s ours
. For instance, if merging the version change ofmaint-0.4.5
intomaint-0.4.6
, do onmaint-0.4.6
this command:git merge -s ours maint-0.4.5
. And then you can proceed with a git-merge-forward. -
For the ChangeLog and ReleaseNotes, you need to write a blurb at the top explaining a bit the release.
-
Review, modify if needed, and merge them upstream.
-
Manually trigger the
maintained
job in theBuild
stage so the CI can build the tarballs without errors.
Once this is done, each selected developers need to build the tarballs in a reproducible way using:
https://gitlab.torproject.org/tpo/core/tor-ci-reproducible
Steps are:
-
Run
./build.sh
which will download everything you need, including the latest tarballs from the release CI, and auto-commit the signatures if the checksum match. You will need to confirm the commits. -
If all is good,
git push origin main
your signatures.