Once the source distribution is produced from the stabilized release branch, the public part of the release process begins. But before the distribution is made available to the world at large, it should be tested and approved by some minimum number of developers, usually three or more. That approval must then be signaled to the world at large, using digital signatures and identifying hashes.
The purpose of signing and hashing is to give users a way to verify that the copy they receive has not been maliciously tampered with. Users are about to run this code on their computers — if the code has been tampered with, an attacker could suddenly have a back door to all their data. (See also the section called “Security Releases”.) The details of creating digital signatures and release hashes are beyond the scope of this book, but if you're not familiar with them, see https://www.apache.org/dev/release-signing.html, and you might also want to do an Internet search for these phrases (simultaneously): "open source" "digital signature" "web of trust".
Gaining developer approval is not simply a matter of them inspecting the release for obvious flaws. Ideally, the developers download the package, build and install it onto a clean system, run the regression test suite (see the section called “Automated testing”), and do some manual testing. Assuming it passes these checks, as well as any other release checklist criteria the project may have, each developer then digitally signs each container (the .tar.gz file, .zip file, etc) using GnuPG (https://www.gnupg.org/) or some other program capable of producing OpenPGP-compliant signatures.
In most projects, the developers just use their personal digital signatures, instead of a shared project key, and as many developers as want to may sign (i.e., there is a minimum number, but not a maximum). The more developers sign, the more testing the release undergoes, and also the greater the likelihood that a security-conscious user can find a web-of-trust path from herself to the release.
Once approved, the release (that is, all tarballs, zip files,
and whatever other formats are being distributed) should be placed
into the project's download area, accompanied by the digital
signatures and hashes.
There are various standards for doing this. One way is to accompany
each released package with a file giving the corresponding digital
signatures, and another file giving the checksum. For example, if one
of the released packages is scanley-2.5.0.tar.gz,
place in the same directory a file
scanley-2.5.0.tar.gz.asc containing the digital
signature for that tarball, another file
scanley-2.5.0.tar.gz.md5 containing its MD5
checksum, perhaps another,
scanley-2.5.0.tar.gz.sha256, containing its SHA256
checksum, etc. A different way to provide checking is to collect all the
signatures for all the released packages into a single file,
scanley-2.5.0.sigs; the same may be done with the
checksums.
It doesn't really matter which way you do it. Just keep to a simple scheme, describe it clearly, and be consistent from release to release.
For important releases containing many changes, many projects
prefer to put out release candidates first,
e.g., scanley-2.5.0-beta1 before
scanley-2.5.0. The purpose of a candidate is to
subject the code to wide testing before blessing it as an official
release. If problems are found, they are fixed on the release branch
and a new candidate release is rolled out
(scanley-2.5.0-beta2). The cycle continues until
no unacceptable bugs are left, at which point the last candidate
release becomes the official release — that is, the only
difference between the last candidate release and the real release
is the removal of the qualifier from the version number.
In most other respects, a candidate release should be treated the same as a real release. The alpha, beta, or rc qualifier is enough to warn conservative users to wait until the real release, and of course the announcements for the candidate releases should point out that their purpose is to solicit feedback. Other than that, give candidate releases the same amount of care as regular releases. After all, you want people to use the candidates, because exposure is the best way to uncover bugs, and also because you never know which candidate release will end up becoming the official release.
Announcing a release is like announcing any other event, and should use the procedures described in the section called “Publicity”. There are a few specific things to do for releases, though.
Whenever you write the URL to the downloadable release tarball, make sure to also write the MD5/SHA1 checksums and pointers to the digital signatures file. Since the announcement happens in multiple forums (mailing list, news page, etc), this means users can get the checksums from multiple sources, which gives the most security-conscious among them extra assurance that the checksums themselves have not been tampered with. Meanwhile, giving the link to the digital signature files multiple times doesn't make those signatures more secure, but it does reassure people (especially those who don't follow the project closely) that the project takes security seriously.
In the announcement email, and on news pages that contain more than just a blurb about the release, make sure to include the relevant portion of the CHANGES file, so people can see why it might be in their interests to upgrade. This is as important with candidate releases as with final releases; the presence of bugfixes and new features is important in tempting people to try out a candidate release.
Finally, don't forget to thank the development team, the testers, and all the people who took the time to file good bug reports. Don't single out anyone by name, though, unless there's someone who is individually responsible for a huge piece of work, the value of which is widely recognized by everyone in the project. Be wary of sliding down the slippery slope of credit inflation (see the section called “Credit”).