My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs. For many of the devs (and users), the first time we get to exercise and interact with some of the new features is during the beta — that is our chance to improve and stabilize it before it goes out the door. If a new API proves awkward in some way, the time to find out and improve it is during the beta. Ideally, we would like both the API and implementation to mature a bit before the release (first draft != final copy). A release candidate is different — that is close to an across-the-board freeze. Once the release happens, bug fixes and documentation tweaks will continue to be checked in for the next micro-release.

Side note: One problem we have is that so few people actually exercise the beta and give useful feedback. To me, the chief value of a public beta is that people get to try it out before everything is set it stone. And reason for having multiple betas is so that we can iterate. If not, perhaps we should just have a single beta, frozen except for bugfixes.

Raymond