Merge branch 'maint-0.2.2'

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.