[boost] 1.34 Release Plan

From: Thomas Witt (witt_at_[hidden])
Date: 2006-01-25 02:48:42

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_at_[hidden]