CM: The Next Generation of SCM Standards

and in that case the Configuration cannot change either.  But a Baseline never changes - it is a frozen Configuration, hopefully, but not necessarily, a consistent one.  The purpose of a Baseline, as its name implies, is to measure change.  How much have we moved on from the Baseline? What's the difference between the item as it is now and how it was in the Baseline?

My Vote: Configuration and Baseline

Configuration:  An aggregation of a set of item revisions.
Baseline:  A frozen Configuration

Build
Build, Build Record, Build Notice, BOM.  So what then is a Build?  Well, Build has three different connotations:  [1] an action, [2] the result of a Build action, [3] a record of a Build[1] action.  Even the action sense is often used as a noun:  I'm doing a Build[1].

A Build[1] takes a Configuration and transforms it into a set of (potential) deliverables, (i.e. the Build[2]).  Most often a Build[1] is done against a non-frozen Configuration - that is, developers creating their own Builds[2] to test their in-progress changes. It's up to the developer to know what incremental changes are being included, and this is done through a Workspace mechanism. But when a "system" Build[1] is done from the CM Repository (i.e. CMDB), it is often important to record exactly what was being built so that if there are problems they can be reproduced, fixed and retested.  But some shops do system builds more than once a day.  Does this mean that a new Baseline has to be created more than once a day in order to track what went into the Build?  Some shops actually do this.  However, if the Build is to reflect a Baseline, does that mean that all 12 Variants of that Build require 12 separate Baselines.  Again some shops actually attempt to do this.  

But a Build[3] Record is a record of what was built.  It is not a Baseline.  I can build the same Baseline with two different versions of a compiler to ensure that both versions give the same result.  Same Baseline, different Builds.  The important thing about a Build[3] Record is that it identifies:

1. the Baseline used
2. Changes used with respect to that Baseline
3. the Variant options used
4. the Tools/Processes used to perform the Build

You can see that several Builds can be performed from the same Baseline.  In general, you "Manage the Baseline and Build the Subset".  That is, your Baseline is an aggregate of all of the possible components that can be used for a Build.  You select Variant Options to customize what you're building from the Baseline.  You add in some Changes that may reflect a new Variant option, but more frequently, fixes Problems and/or adds or extends Features.  You identify the revision of your Tools/Processes that are being used for the Build.  So you might create a Baseline twice a month, but do Builds on that Baseline, adding in all other ready Changes, a couple times a day, or multiple times for different Variants.  Developer Builds are (typically) not tracked so rigorously by the CMDB.  A Build[3] Record, is often referred to simply as a Build[3].  A future Build[3] is sometimes referred to as a Build Notice (similar to Change Notice in the hardware world) or in the past as a Build Record.

Finally, BOM is used in the hardware world to describe the set of part revisions required to build something.  There are a few differences though and so it might be wise to avoid this term.

My Vote: Build, Build Notice, Build Record

Context View
Context, Views, Context Views.