[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor/master] Update releasing-tor to reflect current versions and tooling
commit 1405bdebb0a1d6c92c95b7ef1577856eec776dea
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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).
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits