Definition

As the project progresses and the completeness and stability of baselines improve, "promotion levels" can be used to characterize the baseline in terms of its completeness or stability. Promotion levels and other baseline attributes should be defined as appropriate to meet the needs of the individual project, although you'll typically find that a common set of definitions can be reused in many different projects. Here's an example of promotion levels that might be appropriate to use:

• Integration Tested
• System Tested
• Acceptance Tested
• Production Delivered

In this example, the levels are sequenced to reflect the relative progression in completeness and stability of the software over time. Note that while the software will usually progress forward through these levels, it can also regress in terms of completeness or stability. The act of changing the promotion level of a baseline in the former case is called promoting and in the latter case demoting the baseline.

Explanation

On occasion, the configuration manager may need to demote a baseline by changing its promotion level to one that is lower in the promotion level order. For example, the integrator may discover a a major bug in a newly created baseline. To prevent developers introducing this bug into their development workspaces, the problems with the baseline can also be more clearly indicated by adding a label to the the baseline such as "rejected".

Use

The recommended baseline represents a system configuration that has achieved a specific promotion level. A baseline becomes part of the set of recommended baselines when it is promoted to a certain level, for example, "Acceptance Tested". Promotion levels can be used in project development policies. For example, a policy on a project could be that a given baseline is considered "recommended" when it reaches a particular promotion level. This policy helps to ensure that developers rebase their workspaces whenever a baseline passes an acceptable level of completeness and stability.