Ivan Voras sumarised a little while ago the FreeBSD release procedure:

“It goes something like this (or at least it did/will be for 8.0-RELEASE):

  1. An approximate date is set on one of the DevSummits – this is usually of the granularity of “autumn 2009” rather than a specific day.
  2. As the set date approaches, a more specific deadline is set for a “code freeze”.
  3. Developers try to get as much code into the tree as they can before the code freeze – this is still “free-for-all” time.
  4. After the code freeze, only code specifically approved by the release engineering (releng) team can go in.
  5. During various BETA releases, a RELENG branch – what is known for the users as a “STABLE” branch is created from VCS “head”. Some early beta releases might be cut of the “head” of the tree, latter from the RELENG branch.
  6. Release candidates are cut from the RELENG (STABLE) branch. This is where debugging is turned off system-wide and the performance is as it should be in the released versions. Debugging is never turned back on for STABLE branches (except of course that developers have it on by themeselves).
  7. After a certain amount of BETA and RC releases, the number of which is determined ad-hoc as needed, a release comes out. Everyone is happy, especially developers who can now commit freely to “head” again.
  8. The release engineering period for a major .0 release takes any time from a month to several months.”
  9. To find out more about FreeBSD release engineering, visit the FreeBSD Release Enginering page or Murray Stokely’s Release Document.