commit 3c9ff0af96835575af942a367726732366977581 Author: Nick Mathewson nickm@torproject.org Date: Mon Sep 18 14:49:06 2017 -0400
small tweaks to releasingtor.md --- doc/HACKING/ReleasingTor.md | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index b206b3149..62029b44f 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -8,7 +8,11 @@ new Tor release: === 0. Preliminaries
1. Get at least three of weasel/arma/Sebastian/Sina to put the new - version number in their approved versions list. + version number in their approved versions list. Give them a few + days to do this if you can. + +2. If this is going to be an important security release, give the packagers + some advance warning: See this list of packagers in IV.3 below.
=== I. Make sure it works @@ -26,19 +30,24 @@ new Tor release:
What about Coverity Scan?
+ What about clan scan-build? + Does 'make distcheck' complain?
- How about 'make test-stem' and 'make test-network'? + How about 'make test-stem' and 'make test-network' and + `make test-network-full`?
- Are all those tests still happy with --enable-expensive-hardening ?
Any memory leaks?
-=== II. Write a changelog. +=== II. Write a changelog
-1. Gather the `changes/*` files into a changelog entry, rewriting many +1a. (Alpha release variant) + + Gather the `changes/*` files into a changelog entry, rewriting many of them and reordering to focus on what users and funders would find interesting and understandable.
@@ -83,6 +92,15 @@ new Tor release:
4. Run `./scripts/maint/format_changelog.py --inplace` to make it prettier
+1b. (old-stable release variant) + + For stable releases that backport things from later, we try to compose + their releases, we try to make sure that we keep the changelog entries + identical to their original versions, with a 'backport from 0.x.y.z' + note added to each section. So in this case, once you have the items + from the changes files copied together, don't use them to build a new + changelog: instead, look up the corrected versions that were merged + into ChangeLog in the master branch, and use those.
2. Compose a short release blurb to highlight the user-facing changes. Insert said release blurb into the ChangeLog stanza. If it's @@ -109,7 +127,7 @@ new Tor release: === III. Making the source release.
1. In `maint-0.?.x`, bump the version number in `configure.ac` and run - `scripts/maint/updateVersions.pl` to update version numbers in other + `perl scripts/maint/updateVersions.pl` to update version numbers in other places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`.
(NOTE: To bump the version number, edit `configure.ac`, and then run @@ -165,7 +183,7 @@ new Tor release: 5. Mail the release blurb and ChangeLog to tor-talk (development release) or tor-announce (stable).
- Post the changelog on the the blog as well. You can generate a + 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.