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

violate SCP however, we will definitely "pay the price" either by accepting greater risk, or else imposing other process restrictions and rules (or even creating other codelines) to mitigate that risk.

Next up is OCP. It was pretty easy to apply to baselines, but what about codelines? When a change is made to a codeline, it results in a new "current configuration" of the codeline. This new configuration then becomes the basis for all collaborative work stemming from (and eventually integrated back into) the codeline. If the codeline is "broken" as a result of this change, then it breaks for everyone else that (re)uses that configuration. If that happens, we have just disrupted the flow of collaboration and progress for the codeline. We don't want that! So the essence of a codeline is its "flow"; and we wish to preserve the steady flow of collaboration and progress contributing to the value-stream that the codeline represents:

The Codeline Flow Principle (CLFP):

A Codeline's flow of value must be maintained - it should be open for evolution, but closed against disruption of the progress/collaboration of its users.

The BLIP was about keeping baselines frozen, but the CLFP is about keeping codelines flowing! Laura Wingerd developed an equivalent rule to the CLFP called the Golden Rule of Collaboration :

"Always accept stabilizing changes; Never impose destabilizing changes."

We achieve this by establishing a " codeline invariant ": a set of collaboration criteria/constraints that the codeline's users can rely upon to be preserved. This is often done using a Codeline Policy . The codeline invariant specifies the required degree of 'C'-worthiness (correctness, completeness, consistency, and cadence) of changes flowing through it to enable the needed amount and rate of collaboration and progress.

Last month we interpreted the LSP as a statement of Evolution Integrity , but we need to determine what a "derived container" is. Within the flow of a codeline, the current configuration is "derived from" it's predecessor configuration, as suggested by Anne Mette Hass. So derived "versions" of a codeline should be substitutible for their base versions. This means committing a new change to the codeline must consistently preserve the "correctness" of the codeline. Since the context of the codeline will be "reused" by the next task or workspace-update, each committed configuration must be no less correct or consistent than it's predecessor.

The Codeline Integrity Principle (CLIP):

Newly commited versions of a codeline must consistently be at least as usable as the previous version of the codeline.

For many development shops, this is just a fancy way of saying "Don't break the build!" The basic tenet is to ensure that each change adds value to the codeline without compromising its quality or steady flow of progress.

The way that ISP applies to codelines is regarding integration milestones within a single codeline. This principle is so commonly known to so many that it seems almost too obvious to bother saying, but it nonetheless needs to be said:

The Incremental Integration Principle (IIP):

Define frequent integration milestones that are client-valued.

Many of us know the perils of "big bang integration." But its difficult to know just how frequently and incrementally we should integrate our work and make it visible to "higher" levels of the enterprise. The IIP gives us some general advice, but no specific recommendations. Perhaps the principles relating to evolution granularity can help us?

When applying package cohesion principles to codelines, we arrived at:

The Collaboration/Flow Integration Principle (CFLIP):

The throughput of collaboration is the cumulative flow of integrated changes.

The CFLIP says that collaboration is the source of value-generation (it constitutes