diff options
| author | Roger Dingledine <arma@torproject.org> | 2011-03-08 16:06:32 -0500 |
|---|---|---|
| committer | Roger Dingledine <arma@torproject.org> | 2011-03-08 16:06:32 -0500 |
| commit | dbd4a0175600833c7f84081deaa40fd6294ce1ce (patch) | |
| tree | a2305928ee7948e6df6ee2e0c8acfeb3b9bf507b /doc/HACKING | |
| parent | 0d78a16c3642f7538266e007da79c39860aac332 (diff) | |
| download | tor-dbd4a0175600833c7f84081deaa40fd6294ce1ce.tar tor-dbd4a0175600833c7f84081deaa40fd6294ce1ce.tar.gz | |
steps roger takes when making a new release
Diffstat (limited to 'doc/HACKING')
| -rw-r--r-- | doc/HACKING | 41 |
1 files changed, 41 insertions, 0 deletions
diff --git a/doc/HACKING b/doc/HACKING index f42628b36..32cea9967 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -405,3 +405,44 @@ function should mention that it does that something in the documentation. If you rely on a function doing something beyond what is in its documentation, then you should watch out, or it might do something else later. +Putting out a new release +------------------------- + +Here are the steps Roger takes when putting out a new Tor release: + +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. + +2) 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. + +3) 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 +git branches too. + +4) Bump the version number in configure.in and rebuild. + +5) Make dist, 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. + +6) Get at least two of weasel/arma/karsten to put the new version number +in their approved versions list. + +7) Sign and push the tarball to the website in the dist/ directory. Sign +and push the git tag. + +8) Edit include/versions.wmi to note the new version. Rebuild and push +the website. + +9) Email Erinn and weasel (cc'ing tor-assistants) that a new tarball +is up. This step should probably change to mailing more packagers. + +10) Wait up to a day or two (for a development release), or until most +packages are up (for a stable release), and mail the release blurb and +changelog to tor-talk or tor-announce. + |