Development cycles last about four weeks, starting with three weeks of open development and concluding with at least one week of stabilization. During open development, all checkins are allowed. During stabilization, checkins are restricted to release blockers, low risk fixes, polish, and localizations.
(The stabilization period is also an opportunity to prepare release announcements, finalize documentation, incorporate localizations, and do other release-related work.)
Release drivers meet once per week during open development and once per day during stabilization to triage (prioritize, target, assign) bugs, discuss issues raised in fora that haven't been filed as bugs yet, and keep up with release-related work that isn't tracked in bug reports (like the writing of release announcements).
During the stabilization period, once release blockers are resolved, we build a release candidate and release it to testers. As additional blockers are found and their fixes land during stabilization, we build and release additional such candidates.
On the first day after the end of the stabilization period, or after the most recent release candidate has baked for at least two days without us finding additional blockers (whichever comes later), we release the most recent release candidate as the final release.
(After a final release, we release minor updates to the most recent stable version as needed to address security vulnerabilities, major regressions, and other significant bugs. Minor updates are also an opportunity to incorporate polish and late-landing localizations, although those aren't impeti for the updates.)
We branch the tree after we release the final release.
(Alternately, we branch the tree at the beginning of the stabilization period, giving developers who are not on the hook for stabilization fixes an extra week of open development; or we branch it at some point during the stabilization period when it seems likely that we've resolved all release blockers.)
At the end of each open development period, drivers evaluate progress against a set of 1.0 criteria (to be determined). If we've achieved the 1.0 goals, drivers renumber the release to be 1.0 (which may require a longer than normal stabilization period). Otherwise the release is numbered with the next consecutive integer minor number (i.e. 0.8, 0.9, 0.10, 0.11, etc.).
(Optional: after each of the three weeks of open development, we release testing builds incorporating the latest changes.)