In recent blog posts, we've expanded the long-term support effort to 4.4, discussed the release window (first and third Wednesday of each month), and experimented with release-candidates (RCs) for some point-releases (4.4.6, 4.4.7). This renaissance in release policy prompted a discussion of whether to continue doing RCs for all future releases. The RC concept is still controversial, but we reached a consensus on a similar concept -- nightly builds -- which achieves the original goals (and then some others).
The original goals of the RC experiments were two-fold:
Goal 1 has been mostly addressed by revising and reaffirming the release-window policy (first and third Wednesday) to cover all point-releases. Goal 2 is addressed on an on-going basis with nightly-builds.
A nightly build is an automatic, unsupported build of the CiviCRM source-code -- once each day, an automated script on civicrm.org examines the latest code in CiviCRM's git repositories. For each "tag" or "branch", it prepares installable files (tarballs, zip files) and publishes them on http://dist.civicrm.org . These files may be used for testing purposes.
For production sites, it is important to apply the correct database-upgrade. A bad or inconsistent database-upgrade can cause confusion (at best) and data-loss (at worst). Unfortunately, the database-upgrade is subject to change from day-to-day (until the final day of release). To summarize a few possible paths which are OK or dangerous, let's pick a few examples (e.g. using "4.5.0" as a representative stable release, "4.5.3-20141103" as a representative nightly, and "4.5.3" as another stable release):
An unofficial goal of the RC experiments was to introduce a "freeze" period for point-releases in which the tentative RC could be tested while setting a very high-bar for accepting any further changes. This turned out to be the most controversial aspect of RCs -- and understandably so. During a freeze, new bugfixes may be written but withheld. A freeze involves many debatable decisions, such as (a) how long the freeze should last, (b) how to technically implement the freeze, and (c) which changes are important enough to get in despite a freeze. These factors may be swayed by subjective details (e.g. the release-dates set for the previous and next releases; the overall magnitude of changes in the release; etc).
Consequently, there's no official policy on freeze-periods for point-releases. Unofficially, release-managers may enforce a soft-freeze on particular releases. For example, Eileen (wearing the 4.4 LTS RM hat) plans to implement a soft-freeze for one week before each 4.4.x release. During a soft-freeze, the release-manager holds off on accepting PRs until after the point-release is finalized.