Principles of Agile Version Control: From Object-oriented Design to Project-oriented Branching

1. Propagation : Maintenance lines are used to make fixes and enhancements (value-preserving changes) to help stabilize and maintain an existing release of the software. Such changes are merged (propagated) from a maintenance codeline (where they were already integrated & tested) to a subsequent codeline that will also benefit from the fix (or enhancement).
2. Mainstream Integration & Synchronization : A mainstream integration codeline (mainline) is for integrating the latest & greatest stable state of progress. New development changes are synchronized (or updated or rebaselined/"rebased") from their main (parent) codeline by merging the "current configuration" of the parent to the workspace/branch containing the new development change.

So a codeline basically represents an effort to either maintain the past, coordinate the present, or develop the future. And change-flows either propagate stabilizing change, synchronize shared progress, or promote new value. Note also that both propagation and synchronization are basically updating previous context while promotion is creating new content !

The more future-looking ("progressive") codelines should be synchronized from their more "conservative" parents, but the opposite is not true: more conservative (e.g., maintenance) codelines should not be synchronized from the more "progressive" parents. Given our earlier translation of "abstractness" to "conservative", this would seem to be a valid interpretation of "dependency inversion" as applied to codelines and change-flow:

The Progressive Synchronization Principle (PSP):

Synchronization should flow in the direction of historical progress (from past to present, or from present to future): more conservative codelines should not sync-up with more progressive codelines; more progressive codelines should sync-up with more conservative codelines.

As we might have expected, this is almost the exact equivalent of the second half of Laura Wingerd's Base-Codeline Protocol [8]: changes flow from parent to child only when the child needs to be more stable than the parent. The PSP uses the term "more conservative" instead of more "stable" or more "safe."

Are stability and "conservativism" the same thing? Not according to our "domain translations" from before: we equated stability with "safety" and abstractness with "conservativism." But the very last OOD principle is the Stable Abstractions Principle (SAP), which we'll discuss a little later on.

Similarly, for codelines, there may be many different temptations to branch off a new codeline, but the ones that are significant enough to truly warrant a separate codeline are when the new branch either:

• adds or preserves value for its customers, and/or
• improves or preserves the "flow" of its parent codeline

A prime example of adding/preserving value would be a maintenance branch to support a legacy release. Here it is assumed there is either additional support revenue to be gained, or significant business-loss to be avoided (enough to make it worthwhile to support and maintain the new codeline).

An example of preserving flow would be the Release-Line and Active Development-Line patterns. Ideally, one could get away with using only the release-line, but the difference in audience and criteria for the active-line is enough that it would significantly disrupt the flow of the parent release-line, and/or the parent's collaboration requirements would significantly impose too much development friction against the flow of the child development-line.

So, for codelines, the ISP gives us some rules for when it is appropriate to create a new branch off of the "current" codeline:

The Codeline Branching Principle (CLBP):

Create child branches for value-streams that cannot "go with the flow" of the parent.

Here, "go with flow" simply means that the existing codeline invariant (its required levels of correctness, consistency, completeness, and its cadence) can't meet the needs of both sets of prospective codeline users. So it needs to split by branching off a separate