1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
# 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:
1. 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:
1. 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.
2. 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.
3. 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.
1. Download the generated patches from the `Patches` stage.
Apply these patches to the `main` or `release` branch as appropriate.
(Version bumps apply to `maint`; anything touching the changelog should
apply only to `main` or `release`.)
When updating the version, it will be on `maint` branches and so to
merge-forward, use `git merge -s ours`. For instance, if merging the
version change of `maint-0.4.5` into `maint-0.4.6`, do on `maint-0.4.6`
this command: `git merge -s ours maint-0.4.5`. And then you can proceed
with a git-merge-forward.
2. For the ChangeLog and ReleaseNotes, you need to write a blurb at the top
explaining a bit the release.
3. Review, modify if needed, and merge them upstream.
4. Manually trigger the `maintained` job in the `Build` 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:
1. 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.
2. If all is good, `git push origin main` your signatures.
Once all signatures from all selected developers have been committed:
1. Manually trigger the `signature` job in the `Post-process` stage of the
CI release pipeline.
2. If it passes, the tarball(s) and signature(s) will be available as
artifacts and should be used for the release.
3. Put them on `dist.torproject.org`:
Upload the tarball and its sig to the dist website:
`rsync -avP tor-*.gz{,.asc} dist-master.torproject.org:/srv/dist-master.torproject.org/htdocs/`
Then, on dist-master.torproject.org, run:
`static-update-component dist.torproject.org`
For an alpha or latest stable, open an MR in
https://gitlab.torproject.org/tpo/web/tpo that updates the
`databags/versions.ini` to note the new version.
(NOTE: Due to #17805, there can only be one stable version listed at once.
Nonetheless, do not call your version "alpha" if it is stable, or people
will get confused.)
(NOTE: It will take a while for the website update scripts to update the
website.)
## 3. Post Process
Once the tarballs have been uploaded and are ready to be announced, we need to
do the following:
1. Tag versions (`main` branch or `release` branch as appropriate) using
`git tag -s tor-0.x.y.z-<status>` and then push the tag(s):
`git push origin tor-0.x.y.z-<status>`
(This should be the `main` or `release` branch because that is the one
from which the tarballs are built. We want our tags to match our
tarballs.)
2. Merge upstream the artifacts from the `patches` job in the
`Post-process` stage of the CI release pipeline.
Like step (2.1) above, the `-dev` version bump need to be done manually
with a `git merge -s ours`.
3. Write and post the release announcement for the `forum.torproject.net`
in the `News -> Tor Release Announcement` category.
If possible, mention in which Tor Browser version (with dates) the
release will be in. This usually only applies to the latest stable.
4. Inform `tor-announce@lists.torproject.org` with the releasing pointing to
the Forum. Append the ChangeLog there. We do this until we can automate
such post from the forum directly.
5. Update torproject.org website by submitting a MR to
https://gitlab.torproject.org/tpo/web/tpo
The `databags/versions.ini` file is the one to change with the newly
released version(s).
### New Stable
1. Create the `maint-x.y.z` and `release-x.y.z` branches at the version
tag. Then update the `./scripts/git/git-list-tor-branches.sh` with the
new version.
2. Update `./scripts/git/git-list-tor-branches.sh` and
`./scripts/ci/ci-driver.sh` with the new version in `maint-x.y.z` and
then merge forward into main. (If you haven't pushed remotely the new
branches, merge the local branch).
3. In `main`, bump version to the next series: `tor-x.y.0-alpha-dev` and
then tag it: `git tag -s tor-x.y.0-alpha-dev`
## Appendix: An alternative means to notify packagers
If for some reason you need to contact a bunch of packagers without
using the publicly archived tor-packagers list, you can try these
people:
- {weasel,sysrqb,mikeperry} at torproject dot org
- {blueness} at gentoo dot org
- {paul} at invizbox dot io
- {vincent} at invizbox dot com
- {lfleischer} at archlinux dot org
- {Nathan} at freitas dot net
- {mike} at tig dot as
- {tails-rm} at boum dot org
- {simon} at sdeziel.info
- {yuri} at freebsd.org
- {mh+tor} at scrit.ch
- {security} at brave.com
|
