commit 1405bdebb0a1d6c92c95b7ef1577856eec776dea Author: Nick Mathewson nickm@torproject.org Date: Fri May 26 10:01:04 2017 -0400

Update releasing-tor to reflect current versions and tooling

(Note that a lot of the removed guidance is stuff that the tools will do automatically.) --- doc/HACKING/ReleasingTor.md | 70 +++++++++++++++++++-------------------------- 1 file changed, 30 insertions(+), 40 deletions(-)

diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index 809cd03..4ece4d7 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -26,8 +26,6 @@ new Tor release:

What about Coverity Scan?

- Is make check-spaces happy? - Does 'make distcheck' complain?

How about 'make test-stem' and 'make test-network'? @@ -44,21 +42,16 @@ new Tor release: of them and reordering to focus on what users and funders would find interesting and understandable.

- 1. Make sure that everything that wants a bug number has one. - Make sure that everything which is a bugfix says what version - it was a bugfix on. - - 2. Concatenate them. - - 3. Sort them by section. Within each section, sort by "version it's - a bugfix on", else by numerical ticket order. - - 4. Clean them up: + 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:

- Standard idioms: - `Fixes bug 9999; bugfix on 0.3.3.3-alpha.` + 1. Within each section, sort by "version it's a bugfix on", else by + numerical ticket order.

- One space after a period. + 2. Clean them up:

Make stuff very terse

@@ -86,16 +79,15 @@ new Tor release: maint-0.2.1), be sure to make the stanzas identical (so people can distinguish if these are the same change).

- 5. Merge them in. + 3. Clean everything one last time.

- 6. Clean everything one last time. + 4. Run `./scripts/maint/format_changelog.py --inplace` to make it prettier

- 7. Run `./scripts/maint/format_changelog.py` to make it prettier.

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 - to a release-0.2.x branch, manually commit the changelogs to the later + to a release-* branch, manually commit the changelogs to the later git branches too.

3. If there are changes that require or suggest operator intervention @@ -116,38 +108,40 @@ new Tor release:

=== III. Making the source release.

-1. In `maint-0.2.x`, bump the version number in `configure.ac` and run +1. In `maint-0.?.x`, bump the version number in `configure.ac` and run `scripts/maint/updateVersions.pl` to update version numbers in other - places, and commit. Then merge `maint-0.2.x` into `release-0.2.x`. + places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`.

(NOTE: To bump the version number, edit `configure.ac`, and then run either `make`, or `perl scripts/maint/updateVersions.pl`, depending on your version.)

-2. Make distcheck, put the tarball up somewhere, and tell `#tor` about - it. Wait a while to see if anybody has problems building it. Try to - get Sebastian or somebody to try building it on Windows. +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.)

=== 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.2.x.y-status - git push origin tag tor-0.2.x.y-status + git tag -u <keyid> tor-0.3.x.y-status + git push origin tag tor-0.3.x.y-status

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.

- Edit `include/versions.wmi` and `Makefile` to note the new version. + In the webwml.git repository, `include/versions.wmi` and `Makefile` + 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.)

-3. Email the packagers (cc'ing tor-assistants) that a new tarball is up. +3. Email the packagers (cc'ing tor-team) that a new tarball is up. The current list of packagers is:

- {weasel,gk,mikeperry} at torproject dot org @@ -156,11 +150,7 @@ new Tor release: - {lfleischer} at archlinux dot org - {Nathan} at freitas dot net - {mike} at tig dot as - - {tails-rm} at boum dot org (for pre-release announcments) - - - - {tails-dev} at boum dot org (for at-release announcements) - + - {tails-rm} at boum dot org

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 @@ -176,17 +166,17 @@ new Tor release: blog-formatted version of the changelog with the -B option to format-changelog.

- When you post, include an estimate of when the next TorBrowser releases - will come out that include this Tor release. + 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.

=== V. Aftermath and cleanup

-1. If it's a stable release, bump the version number in the `maint-x.y.z` - branch to "newversion-dev", and do a `merge -s ours` merge to avoid - taking that change into master. Do a similar `merge -s theirs` - merge to get the change (and only that change) into release. (Some - of the build scripts require that maint merge cleanly into release.) +1. If it's a stable release, bump the version number in the + `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).