One of the first priniciples we considered here was some sort of single configuration principle that would be an application of the SRP to baselines. A baseline should correspond to one and only one configuration. The single configuration might include other configurations, but the intent is to represent a single configuration for a single purpose. This didn’t seem significant enough to warrant having as a principle. If you disagree, please email us and tell us why, as we are eager for your feedback.
For baselined versions, identity preservation (our translation of OCP) means that if I baseline a version and label/tag the result, then that resulting version name should always correspond to that same set of file versions. It's not okay if it refers to version ten of file “helloworld.c” one day, but refers to version 11 of the same file a week later. If I baseline a version, it means I'm planning on handing it over to some consumer using that version name and making a promise that the version name will forever correspond to that very same content every day thereafter for as long as the project and product is still in use.
The Baseline Integrity Principle (BLIP)
A baseline's historical integrity must be preserved - it must always accurately correspond to what its content was at the time it was baselined. Damon Poole's Timesafe Property makes a very similar statement, but is more focused on the property of an SCM system that is necessary to preserve a baseline's historical accuracy. It assumes that BLIP is already a given and discusses a necessary mechanism to ensure it. From the perspective of dependency management, BLIP is important because it makes a statement about the dependability of baselines and the dependency upon the immutability of the contents associated with the baseline:
· When we depend upon a baseline, we are depending on the corresponding items and their versions in that baseline.
· This means that the baseline must maintain referential integrity to its constituent elements and versions ; it must always correspond to the same set of elements & versions.
· As that baseline becomes more mature and progresses through increasingly higher levels of visibility, the more things there will be that reference it and depend upon it, and the more sacrosanct its dependability becomes.
Last month, we translated ISP to be defining fine-grained acceptance criteria that are client-specific. For configurations, including changes and baselines, this means that the promotion-lifecycle should define its promotion-levels based on acceptance/ readiness criteria for transitioning from one level of user-visibility to another.
The Promotion Leveling Principle (PLP)
Define fine-grained promotion-levels that are consumer/role-specific. One can define numerous levels of quality assurance, but the ones that are important enough to represent new milestones in the evolution of a configuration are when that configuration has successfully transitioned to the next-level consumer in the value-chain.