|
@@ -20,30 +20,29 @@ new Tor release:
|
|
|
|
|
|
=== I. Make sure it works
|
|
|
|
|
|
-1. Use it for a while, as a client, as a relay, as a hidden service,
|
|
|
- and as a directory authority. See if it has any obvious bugs, and
|
|
|
- resolve those.
|
|
|
+1. Make sure that CI passes: have a look at Travis, Appveyor, and
|
|
|
+ Jenkins. Make sure you're looking at the right branches.
|
|
|
|
|
|
- As applicable, merge the `maint-X` branch into the `release-X` branch.
|
|
|
- But you've been doing that all along, right?
|
|
|
+ If there are any unexplained failures, try to fix them or figure them
|
|
|
+ out.
|
|
|
|
|
|
-2. Are all of the jenkins builders happy? See jenkins.torproject.org.
|
|
|
+2. Verify that there are no big outstanding issues. You might find such
|
|
|
+ issues --
|
|
|
|
|
|
- What about the bsd buildbots?
|
|
|
- See http://buildbot.pixelminers.net/builders/
|
|
|
+ * On Trac
|
|
|
|
|
|
- What about Coverity Scan?
|
|
|
+ * On coverity scan
|
|
|
|
|
|
- What about clang scan-build?
|
|
|
+ * On OSS-Fuzz
|
|
|
|
|
|
- Does `make distcheck` complain?
|
|
|
+3. Run checks that aren't covered above, including:
|
|
|
|
|
|
- How about `make test-stem` and `make test-network` and
|
|
|
- `make test-network-all`?
|
|
|
+ * clang scan-build. (See the script in ./scripts/test/scan_build.sh)
|
|
|
|
|
|
- - Are all those tests still happy with --enable-expensive-hardening ?
|
|
|
+ * make test-network and make test-network-all (with
|
|
|
+ --enable-expensive-hardening)
|
|
|
|
|
|
- Any memory leaks?
|
|
|
+ * Running Tor yourself and making sure that it actually works for you.
|
|
|
|
|
|
|
|
|
=== II. Write a changelog
|
|
@@ -55,11 +54,14 @@ new Tor release:
|
|
|
of them and reordering to focus on what users and funders would find
|
|
|
interesting and understandable.
|
|
|
|
|
|
- To do this, first run `./scripts/maint/lintChanges.py changes/*` and
|
|
|
- fix as many warnings as you can. Then run `./scripts/maint/sortChanges.py
|
|
|
- changes/* > changelog.in` to combine headings and sort the entries.
|
|
|
- After that, it's time to hand-edit and fix the issues that lintChanges
|
|
|
- can't find:
|
|
|
+ To do this, run
|
|
|
+ `./scripts/maint/sortChanges.py changes/* > changelog.in`
|
|
|
+ to combine headings and sort the entries. Copy the changelog.in file
|
|
|
+ into the ChangeLog. Run 'format_changelog.py' (see below) to clean
|
|
|
+ up the line breaks.
|
|
|
+
|
|
|
+ After that, it's time to hand-edit and fix the issues that
|
|
|
+ lintChanges can't find:
|
|
|
|
|
|
1. Within each section, sort by "version it's a bugfix on", else by
|
|
|
numerical ticket order.
|
|
@@ -68,8 +70,6 @@ new Tor release:
|
|
|
|
|
|
Make stuff very terse
|
|
|
|
|
|
- Make sure each section name ends with a colon
|
|
|
-
|
|
|
Describe the user-visible problem right away
|
|
|
|
|
|
Mention relevant config options by name. If they're rare or unusual,
|
|
@@ -81,6 +81,8 @@ new Tor release:
|
|
|
|
|
|
"Relays", not "servers" or "nodes" or "Tor relays".
|
|
|
|
|
|
+ "Onion services", not "hidden services".
|
|
|
+
|
|
|
"Stop FOOing", not "Fix a bug where we would FOO".
|
|
|
|
|
|
Try not to let any given section be longer than about a page. Break up
|
|
@@ -106,6 +108,8 @@ new Tor release:
|
|
|
changelog: instead, look up the corrected versions that were merged
|
|
|
into ChangeLog in the master branch, and use those.
|
|
|
|
|
|
+ Add "backport from X.Y.Z" in the section header for these entries.
|
|
|
+
|
|
|
2. Compose a short release blurb to highlight the user-facing
|
|
|
changes. Insert said release blurb into the ChangeLog stanza. If it's
|
|
|
a stable release, add it to the ReleaseNotes file too. If we're adding
|
|
@@ -142,33 +146,50 @@ new Tor release:
|
|
|
master, merge it with "-s ours" to avoid a needless version bump.
|
|
|
|
|
|
2. Make distcheck, put the tarball up in somewhere (how about your
|
|
|
- homedir on your homedir on people.torproject.org?) , and tell `#tor`
|
|
|
- about it. Wait a while to see if anybody has problems building it.
|
|
|
- (Though jenkins is usually pretty good about catching these things.)
|
|
|
+ homedir on your homedir on people.torproject.org?) , and tell `#tor-dev`
|
|
|
+ about it.
|
|
|
+
|
|
|
+ If you want, wait until at least one person has built it
|
|
|
+ successfully. (We used to say "wait for others to test it", but our
|
|
|
+ CI has successfully caught these kinds of errors for the last several
|
|
|
+ years.)
|
|
|
+
|
|
|
+
|
|
|
+3. Make sure that the new version is recommended in the latest consensus.
|
|
|
+ (Otherwise, users will get confused when it complains to them
|
|
|
+ about its status.)
|
|
|
+
|
|
|
+ If it is not, you'll need to poke Roger, Weasel, and Sebastian again: see
|
|
|
+ item 0.1 at the start of this document.
|
|
|
|
|
|
=== IV. Commit, upload, announce
|
|
|
|
|
|
1. Sign the tarball, then sign and push the git tag:
|
|
|
|
|
|
gpg -ba <the_tarball>
|
|
|
- git tag -u <keyid> tor-0.3.x.y-status
|
|
|
- git push origin tag tor-0.3.x.y-status
|
|
|
+ git tag -s tor-0.4.x.y-<status>
|
|
|
+ git push origin tag tor-0.4.x.y-<status>
|
|
|
+
|
|
|
+ (You must do this before you update the website: the website scripts
|
|
|
+ rely on finding the version by tag.)
|
|
|
|
|
|
- (You must do this before you update the website: it relies on finding
|
|
|
- the version by tag.)
|
|
|
+ (If your default PGP key is not the one you want to sign with, then say
|
|
|
+ "-u <keyid>" instead of "-s".)
|
|
|
|
|
|
2. scp the tarball and its sig to the dist website, i.e.
|
|
|
- `/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want
|
|
|
- it to go live, you run "static-update-component dist.torproject.org"
|
|
|
- on dist-master.
|
|
|
+ `/srv/dist-master.torproject.org/htdocs/` on dist-master. Run
|
|
|
+ "static-update-component dist.torproject.org" on dist-master.
|
|
|
|
|
|
In the webwml.git repository, `include/versions.wmi` and `Makefile`
|
|
|
- to note the new version.
|
|
|
+ to note the new version. Push these changes to master.
|
|
|
|
|
|
(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. Email the packagers (cc'ing tor-team) that a new tarball is up.
|
|
|
The current list of packagers is:
|
|
|
|
|
@@ -186,29 +207,35 @@ new Tor release:
|
|
|
|
|
|
Also, email tor-packagers@lists.torproject.org.
|
|
|
|
|
|
+ Mention where to download the tarball (https://dist.torproject.org).
|
|
|
+
|
|
|
+ Include a link to the changelog.
|
|
|
+
|
|
|
+
|
|
|
4. Add the version number to Trac. To do this, go to Trac, log in,
|
|
|
select "Admin" near the top of the screen, then select "Versions" from
|
|
|
the menu on the left. At the right, there will be an "Add version"
|
|
|
box. By convention, we enter the version in the form "Tor:
|
|
|
- 0.2.2.23-alpha" (or whatever the version is), and we select the date as
|
|
|
+ 0.4.0.1-alpha" (or whatever the version is), and we select the date as
|
|
|
the date in the ChangeLog.
|
|
|
|
|
|
-5. Double-check: did the version get recommended in the consensus yet? Is
|
|
|
- the website updated? If not, don't announce until they have the
|
|
|
- up-to-date versions, or people will get confused.
|
|
|
+5. Wait for the download page to be updated. (If you don't do this before you
|
|
|
+ announce, people will be confused.)
|
|
|
|
|
|
6. Mail the release blurb and ChangeLog to tor-talk (development release) or
|
|
|
tor-announce (stable).
|
|
|
|
|
|
Post the changelog on the blog as well. You can generate a
|
|
|
- blog-formatted version of the changelog with the -B option to
|
|
|
- format-changelog.
|
|
|
+ blog-formatted version of the changelog with
|
|
|
+ `./scripts/maint/format_changelog.py --B`
|
|
|
|
|
|
When you post, include an estimate of when the next TorBrowser
|
|
|
releases will come out that include this Tor release. This will
|
|
|
usually track https://wiki.mozilla.org/RapidRelease/Calendar , but it
|
|
|
can vary.
|
|
|
|
|
|
+ For templates to use when announcing, see:
|
|
|
+ https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/AnnouncementTemplates
|
|
|
|
|
|
=== V. Aftermath and cleanup
|
|
|
|
|
@@ -216,7 +243,7 @@ new Tor release:
|
|
|
`maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours`
|
|
|
merge to avoid taking that change into master.
|
|
|
|
|
|
-2. Forward-port the ChangeLog (and ReleaseNotes if appropriate).
|
|
|
+2. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the
|
|
|
+ master branch.
|
|
|
|
|
|
3. Keep an eye on the blog post, to moderate comments and answer questions.
|
|
|
-
|