Planning
The beginning of a development cycle starts with planning the features and major refactorings that need to be done. These features are then prioritized and assigned to individual developers in the Issue tracker. Priority 1 means that the feature is considered mandatory for the next version. Priority 2 are items that we'd really like to get done, but are not absolutely required. Most of the priority 3 items will probably not make it into that version.

Feature development
We then do feature development for approximately six weeks. For each version, there is a set date by which all feature work should be done.

Stabilization
We then switch to stabilization mode. All developers should be done working on features and should be fixing bugs. As part of this process, we do buddy testing. Buddy testing involves choosing a set of features that another developer worked on and testing those features, opening bugs as you find problems. We also do some performance and memory profiling work to find problems that may have been introduced.

There is a set date by which all developers should have either fixed all their bugs or deferred them to the next milestone, the zero-bug bounce. This is typically about two weeks after the feature complete deadline.

Shortly after the bounce, we create a release branch for the new version. At this point, all changes need to be associated with a bug in the issue tracker, have approval from the triage committee, and been code-reviewed by another developer before they are checked in. The name of the code reviewer and the bug numbers should be part of the checkin description.

After branching, we work to close all of the bugs that were resolved as part of stabilization. Closing a bug means testing the the fix actually addressed the problem that the bug was reporting. We test against our own developer machines, and also deploy new builds to the staging servers for additional testing.

During this time, developers who have completed their obligations for the milestone can start planning and feature coding on the trunk. We hold off on making any database schema changes until the release is officially done since it creates problems when trying to merge schemas.

Deployment
Once we're relatively confident that the known bugs have been fixed, typically about a week after the zero bug bounce, we deploy to some of our customer's web sites for some real-world usage. We fix any additional bugs that are critical, deploying updated releases to the customer machines.

Usually about a week later, we consider the release officially complete and make installers available for download. We will also merge all the bug fixes that we made in the release branch back to the trunk.

A calendar containing specific dates for the current release can be found here.