Releasing

Generally Good Habits

To assist the release process, two things would be useful:

Add significant changes to the relevant Releases page as they are made. Even if they are not world-changing, it shows what is new since the last release (which could assist in the decision about when to release). It's easier to remove minor changes from the list than to go through the Changelog months later.
Update documents as you go and don't let them get into a state like pre-0.8.2.

How to get to a release

Call for code freeze two week before it'll happen.
Verify the Releases page has a link to the coming release, and put it in shape.
Test, test, test.
Update translation (po) files.
Branch on the code freeze day (branch_#_#_#).
Put out a call on gnash-dev for updated Translations, preferably in its own email so it doesn't get overlooked.
Test, test, test.
Change version, update the NEWS file.
Test, test, test.
Tag release_#_#_#_rc#, upload and call community for testing.
Test, test, test.
After a week, if anything changed, goto(-2) [tag, upload and call].
Otherwise, tag release_#_#_#_final.

This is a shortlist of things to do to effect a release. This is after the code freeze, when the tarballs have been created.