Overview
There is a constant desire for more code changes to fix bugs and add features. However, at some point we must select what will go into the next release or pre-release in order to stabilize the code. Building for and testing on additional platforms may reveal subtle problems in recent changes that hadn't been noticed previously. It's important to take the time to focus on correcting such problems before making a release.
Our intent is to do this by dividing the work of preparing releases into phases. By explicitly describing these and declaring which phase of the releae process we are working in, we can quickly decide whether it is appropriate to begin working on new code changes or to defer such work until a later time.
We don't want to make this model too rigid or too complicated, but clearly we need at least a little structure to help us make forward progress. This page will explain the phases of the release process to help developers make decisions about their work.
Phase 1: Open
This is the phase where most development time is spent. Features and bug fixes are implemented in code changes and selected for inclusion in the up-coming release.
Phase 2: Cool Down
At this point, development should be mostly complete but some of the code changes may still need finishing touches. New changes should be limited. Work on testing across the full range of platforms should commence.
Phase 3: Freeze
At this point code changes should be limited to those fixing problems discovered during testing. Testing across the full range of platforms should continue, and installable packages should be created.