mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-20 13:06:20 +02:00
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.)
This commit is contained in:
parent
61625b8f26
commit
1405bdebb0
@ -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.
|
||||
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:
|
||||
|
||||
2. Concatenate them.
|
||||
1. Within each section, sort by "version it's a bugfix on", else by
|
||||
numerical ticket order.
|
||||
|
||||
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:
|
||||
|
||||
Standard idioms:
|
||||
`Fixes bug 9999; bugfix on 0.3.3.3-alpha.`
|
||||
|
||||
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).
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user