Re: [boost] [release management] Draft policy for changes between betaand release

Subject: Re: [boost] [release management] Draft policy for changes between betaand release
From: John Maddock (john_at_[hidden])
Date: 2008-10-23 10:50:45

Beman Dawes wrote:
>> 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.

Nod.

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

OK, but the author should verify that changes don't break the main doc build 
if that's effected.

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

Although it's more work, my gut feeling is that the release team should be 
involved in that.

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

Probably not likely to be given if they're not showstoppers?

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

Nod.

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

Nod.

John.