Our interpretation of the Single Responsibility Principle for Codelines is:
The Serial Commit Principle (SCP)
A Codeline, or workspace, should receive changes (commits/updates) to a component from only one source at a time. Whereas STWP was about the act of making/creating change, SCP is about the act of integrating change and synchronizing the contents of a container. SCP says that, while it is perfectly normal for multiple people to work on many different things during the time, only one source at a time (a workspace or another codeline) should be allowed to transfer changes to our codeline. There should be no concurrent commits attempting to update the same codeline for the same component at the same time.
In practice, strict adherance to SCP might be controversial, particularly to those claiming it imposes a severe bottleneck on the flow of development changes when a large number of people are working on the same codeline, or a lot of very small non-overlapping tasks are happening during the same period of time. If we do decide to 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 integrating back into, the codeline. If the codeline is broken as a result of this change, it then 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. The essence of a codeline is its flow and our goal is 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 codelinepolicy. 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. Because of this, derived versions of a codeline should be able to be substituted for their base versions. This means that 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.