Advance rebase operations

Most development streams over the life of a project advance from predecessor baselines to descendant baselines that integrate work performed in the project. Streams are usually allowed to advance (see Advance rebase operation).
Figure 1: Advance rebase operation

Project A has an integration stream and two development streams D1 and D2. Stream D1 delivers its activities to the integration stream, followed by stream D2. Later, streams D1 and D2 rebase to a baseline in the integration stream to pick up the latest changes that both streams previously delivered.

Development streams D1 and D2 deliver work (activities a1, a2, a3, b1, b2, and b3) to the integration stream. In the integration stream, a descendant baseline PA.BL2 is made to capture the work. To include the new work in their configurations, streams D1 and D2 rebase to descendant baseline PA.BL2.

Restrictions on advancing rebase operations occur when the descendant baseline is not from the parent stream. In a rebase operation, you can select a baseline from any stream. For example, you can select a baseline from a stream that is a descendant of the stream foundation that is in a stream that is not its parent stream. Thus, a development stream could rebase to a baseline created in a sibling development stream. Therefore, the rebasing stream could acquire work that has not been delivered to the parent stream. If several streams were allowed to deliver the same work, there would be confusion during the merge operation. (Alternative target delivery is a special case, and a project manager can set policies to allow a stream to accept changes that did not originate in the delivering stream).

A common example of an advance rebase operation occurs when a project uses a test stream (see A test stream to stabilize a baseline). The project integrator creates the baseline PA.BL1 for a milestone. The work to stabilize the code in the baseline is done on the test stream DS that is dedicated to this task. Because the project A integration stream can have more activities delivered as the baseline PA.BL1 is being tested, the integration stream is not used. The test stream is isolated from deliver operations ongoing in the parent stream, the project A integration stream.
Figure 2: A test stream to stabilize a baseline

Project A had stream D1 that is created with baseline PA.BL0 and stream DS (the test stream) that is created with baseline PA.BL1 in the integration stream. Fixes in the test stream are delivered in baseline PA.BL1.S to the integration stream and are shared with stream D1 in a rebase operation. Stream D1 delivers its changes later to the integration stream.

Although the PA.BL1.S baseline is a descendant of their current foundation baseline PA.BL0, development streams like D1 are not allowed to rebase to it. If this rebase operation were allowed, the development streams could deliver the build stabilization work before stream DS does. Therefore, the test stream DS must first deliver its work in the baseline PA.BL1.S to the parent of the development streams, the project A integration stream. When the work from test stream DS is contained in the parent stream and the baseline that contains that work is ready to be released, the project integrator can recommend the baseline. Then the development streams can rebase to the baseline PA.BL1.S from the test stream.
Tip: The deliver operation changes the relationship between baselines in a stream. In A test stream to stabilize a baseline, when a new baseline PA.BL2 is created in the project A integration stream, it becomes a descendant of PA.BL1 as with any baseline, but it also becomes a descendant of PA.BL1.S from the test stream. Because baseline PA.BL1.S was delivered to the integration stream, baseline PA.BL2 contains baseline PA.BL1.S, which is a requirement of the predecessor and descendant relationship.