We normally have one person acting as the release manager, who organizes development for the release and also actually makes the release tarball and posts announcements. It can be a different person from one release to the next.
Our usual process is that one week before release we will make a release branch from the trunk. We do one commit to that branch to change the version number to 'rc1', and advance the trunk version to 'dev' for the next release.
We then publish and announce this release candidate according to the process below. We then have a week of general testing of the rc, including some time for plugin authors to update their code for any changes.
Normally no changes will be made on the release branch unless serious bugs or regressions are found, and the release manager decides they should be merged in. After one week, the release branch's version number is updated and it's published as the final release. If regressions or serious problems are discovered after the final release we may make an additional point release from that branch.
The process or timing can vary if that seems appropriate in a particular case but we try to release on a regular four week cycle.
The net effect is that the code gets some extra testing before release, and the trunk is always open for general development.
To start a new release cycle:
Every week the release manager should send a mail to the Bazaar list covering these points (as appropriate):
When it's time to make the release candidate: