diff options
Diffstat (limited to 'doc/HACKING')
| -rw-r--r-- | doc/HACKING | 39 |
1 files changed, 26 insertions, 13 deletions
diff --git a/doc/HACKING b/doc/HACKING index 7ff9c5f3c2..bc409dc0d0 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -426,10 +426,10 @@ interesting and understandable. first entry or two and the last entry most interesting: they're the ones that skimmers tend to read. - 2.4) Clean them up + 2.4) Clean them up: Standard idioms: - "Fixes bug 9999; Bugfix on 0.3.3.3-alpha." + "Fixes bug 9999; bugfix on 0.3.3.3-alpha." One period after a space. @@ -446,6 +446,11 @@ interesting and understandable. Present and imperative tense: not past. + Try not to let any given section be longer than about a page. Break up + long sections into subsections by some sort of common subtopic. This + guideline is especially important when organizing Release Notes for + new stable releases. + If a given changes stanza showed up in a different release (e.g. maint-0.2.1), be sure to make the stanzas identical (so people can distinguish if these are the same change). @@ -456,7 +461,6 @@ interesting and understandable. 2.7) Run it through fmt to make it pretty. - 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 @@ -469,18 +473,22 @@ git branches too. 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 +6) Get at least two of weasel/arma/sebastian 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. - (That's either "git tag -u <keyid> tor-0.2.x.y-status", then - "git push origin tag tor-0.2.x.y-status". To sign the - tarball, "gpg -ba <the_tarball>". Put the files in - /srv/www-master.torproject.org/htdocs/dist/ on vescum.) +7) 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 + +8) scp the tarball and its sig to the website in the dist/ directory +(i.e. /srv/www-master.torproject.org/htdocs/dist/ on vescum). Edit +include/versions.wmi to note the new version. From your website checkout, +run ./publish to build and publish the website. -8) Edit include/versions.wmi to note the new version. From your website -checkout, run ./publish to build and publish the website. +Try not to delay too much between scp'ing the tarball and running +./publish -- the website has multiple A records and your scp only sent +it to one of them. 9) Email Erinn and weasel (cc'ing tor-assistants) that a new tarball is up. This step should probably change to mailing more packagers. @@ -492,9 +500,14 @@ box. By convention, we enter the version in the form "Tor: 0.2.2.23-alpha" (or whatever the version is), and we select the date as the date in the ChangeLog. -11) Wait up to a day or two (for a development release), or until most +11) Forward-port the ChangeLog. + +12) Update the topic in #tor to reflect the new version. + +12) 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. (We might be moving to faster announcements, but don't announce until the website is at least updated.) + |