Hi, with 1.33.0 now five months old it is time to get the 1.34.0 release going. Well to be honest it's probably more than time. In order to improve our release process we are planning to adopt a staged release process that is modelled partly after the gcc release process. By and large it can be seen as a formalization of things already done in past releases. A description of the different stages will be given at the end of this mail. But lets get the important issues out of the way first: schedule. I think that we have enough features in CVS already to make 1.34 worthwhile. For that reason the main focus for 1.34 will be a release within reasonable time. For that reason I am going to aim for a feature freeze (Stage 3) in two weeks from now. I ask anybody who can not make that deadline for one reason or another to contact me directly and we try to figure something out. Furthermore for this release feature freeze will also be the cut off date for addition of new libraries. I am planning to flesh out the further schedule in a few days once I got an idea how we are doing with the feature freeze. Thanks Thomas Boost Release Procedure (by Doug Gregor) ==================== Boost development for each release will be divided into four stages, influenced by the GCC development model. The stages move from a very loose, open development model where major changes can be made toward a much more tightly-controlled model as the release date nears. Release managers are appointed for the duration of the release process for a particular version of Boost, and several Boost versions may be in progress at any point in time. However, actual release dates will be staggered to allow testing resources to be allocated to the most imminent release. Stage 1 - Open Development -------------------------- Major changes to libraries or infrastructure may be performed, including large updates or additions to core libraries (e.g., type traits) and tools (e.g., Boost.Build). New libraries and new features can be added freely. Stage 2 - Intracomponent Open Development ----------------------------------------- This stage restricts Stage 1 slightly by banning far-reaching changes to Boost. Major changes to libraries or infrastructure, or the addition of new features and libraries, can be made in the stage. However, the changes must be limited in scope and may not have far-reaching affects. For instance, the build or regression testing systems in Boost cannot be changed at this point, and Boost libraries on which other major components of Boost depend (such as MPL, Type Traits, and Config) may not have large interface changes or be fundamentally rewritten. The Release Manager has final say regarding the classification of changes as "far-reaching" or not; if you are unsure, please ask. Stage 3 - Feature freeze ------------------------ This stage is a bug-fixing stage. Bug fixes may be freely applied to Boost, even if they require substantial changes. Interfaces may not be changed (unless required to fix bugs) and new features should be added only sparingly and with Release Manager approval. New libraries may be introduced at this stage with Release Manager approval, but the introduction of new libraries is tentative: if the new library fails a significant number of its regression tests, it will be removed from the release. Stage 4 - Release preparation ----------------------------- Only bug-fixes and documentation changes may be applied, and the changes should be as minimal and as safe as possible. If a change is large, or has the potential to cause additional failures, consult the Release Manager before applying the change to the repository. Changes that cause failures will be reverted after 48 hours if the failures are not addressed to the Release Manager's satisfaction. The beginning of stage 4 will be marked by the creation of a new CVS branch for the release. At this point, the old CVS branch falls back to stage 1 (for major releases, e.g., 1.XX.0) or stage 3 (for minor releases, e.g., 1.XX.Y). Final Freeze ------------ 7 days prior to a release, the Release Manager will call for a final freeze on the CVS branch corresponding to the release. At this point, no changes may be made to the branch with explicit Release Manager approval. Post-Release ------------ After a release is made, the changes made on the release branch should be merged back into its parent branch. The release branch reverts to stage 4; should another minor release be scheduled on that branch, the Release Manager for that minor version may revert to stage 3 or remain in stage 4 until the point release is imminent. Thomas Witt witt@acm.org