[boost] [release management] Draft policy for changes between beta and release

Subject: [boost] [release management] Draft policy for changes between beta and release
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-10-23 10:11:22

In another post, John Maddock asked what sort of QA problems should be 
fixed between the beta and final releases, and what the criteria and 
procedures are.

Here is a quick draft of a possible policy:

*  Showstoppers. Criteria: Bugs or other problems so serious that the 
release is seriously compromised if not fixed. Procedure: After 
discussion on the developers list, release managers will specify how the 
problem is to be attacked, and what effect it will have on schedule.

* Documentation and other minor fixes not affecting code. Criteria: 
Changes not requiring regression testing and unlikely to impact other 
libraries. Procedure: Merges to branches/release are OK, after fix 
applied to trunk, and do not require a release manager's permission.

* Minor code fixes. Criteria: Changes believed to have limited risk and 
that have already been made to trunk and are stable on trunk regression 
testing. Procedure: Merges to branches/release after fix stable on trunk 
tests do not require a release manager's permission.

* Questionable code fixes. Criteria: Any code changes not meeting the 
"Minor code fix" criteria, such as a change with a lot of possible 
ripple effect on other libraries. Procedure: Ask release managers for 
permission.

* Tools changes and fixes. Code changes to bjam, Boost.Build, 
Boost.Test, the doc build process, and other tools are discouraged late 
in release cycles in general and between beta and release in particular. 
Ask release managers for permission if you really think the change is 
warranted for this release.

* New features, breaking changes, major reworks, new libraries. These 
are not suitable for merging between beta and release. Wait until the 
next release.

Comments?

--Beman