Beta Merge Policy

Introduction

These branches/release merge policies cover the period between when a beta ships and the final release. They are intended to ensure quality, yet avoid requiring developers get permission for certain routine commits.

Policy

The criteria and procedures for merges to branches/release during a beta period are based upon the specifics of the problem being addressed:

• 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.

• Code changes and fixes. Procedure: Ask release managers for permission. Libraries with regressions showing in trunk testing should not be merged into the release branch. If it is discovered that this has occurred, then the merge should be reverted. Rationale: While we do want to fix problems, particularly regressions, stability is a major concern at this point in the release cycle.

• Documentation fixes and other minor changes 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. Important: If applicable, check the daily snapshot to verify the change did not break the documentation build.

• 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.

Comment

One factor considered by release managers in approving code changes is whether the fix is for a regression relative to the last release or a fix to a long-standing problem. From the point of view of an end-user, the difference between the new version "still not working" and "being more broken than the last" is significant. Even uncomfortably large fixes may be accepted if they are fixing regressions, while minor fixes that do not fix regressions will only be accepted if obviously harmless.

Acknowledgments

Joaquín M López Muñoz, John Maddock, Robert Ramey, and Phil Endecott made helpful suggestions during the development of this policy.

---

Copyright Beman Dawes 2008

Distributed under the Boost Software License, Version 1.0. (See http://www.boost.org/LICENSE_1_0.txt)