Composite baselines in release-oriented projects

In release-oriented projects, use composite baselines to shorten recommended baseline lists. Using composite baselines makes it easier to tell which baselines were recommended at different times. The composite baselines can be used to represent major subsystems in the product. Or, in the simplest case, a project can consolidate all of its baselines into a single component, which it recommends and delivers to follow-on projects.

Additionally, using a single composite baseline to represent the final product (that is, collecting baselines from all of the components) reduces the occurrence of baseline conflicts. If a project uses a single composite baseline for the final product, the project integrator can implement a process rule that forces all builds to occur from the top-level component. This process rule reduces the probability of a developer inadvertently introducing conflicts.

Developers can still choose to use baseline overrides when they need to access materials that are not included in the recommended baseline set. For example, if a developer needs a bug fix that has not yet been included in a recommended baseline, the developer can rebase to the appropriate baseline for the specific component containing the bug fix, even if there is no baseline conflict.

Take care when you use baseline overrides to share code in this way, because you can introduce a conflict into a stream. Baseline conflicts can occur when more than one composite baseline is overridden — but only when the overridden baselines are composite baselines. Baseline conflicts cannot be created if a single composite baseline is overridden or if baselines of components that are not members of other components are overridden.