The Interface Segregration Principle for OOD states, “make fine-grained interfaces that are client-specific.” All consumers of a class should be partitioned into one or more client types and a separate abstract interface should be defined for each type of client the class must serve.
Interfaces are a form of abstraction and for version control we believe that translates into acceptance criteria for the users of a container and also a level of visibility of a container. For version control, interface segregation can be applied to changes, baselines, and codelines:
- For changes, there are the times when they are private and still in-progress and then are subsequently ready to be promoted in visibility and used in progressively more public scopes of the enterprise.
- For baselines, their contents do not change. What changes is the level of assurance we have as to their overall quality and readiness for production release/deployment. An in-progress change is just an initial, private and not yet promoted state of a configuration that may eventually be baselined and further promoted.
- For codelines, their contents do change and evolve, sometimes to the point where it needs to be decided whether or not to branch a new codeline to support a parallel path of evolution.
All of these are really just forms of Visible IncrementalEvolution, when restating the general form of ISP in terms of version-control containers: Make fine grained acceptance-criteria that are client-specific.
Reuse, Release and Evolution Granularity
The OOD principles of reuse-release equivalence, common closure, and common reuse are all about the appropriate granularity of packages of classes. We wish to investigate the corresponding granularity of packages of evolution within a version control environment. We can consider the scope and granularity of a change, a baseline, a codeline, and beyond. In either case, both (re)use and release imply reuse by some consumer and releasing to some target consumer. Once again, the notion of abstractness in OOD translates to the level of visibility of versioned content that will play a key role.
In version control, the reuse of changes and versions occurs when we view or update (merge/modify) a version of one or more files in our workspace in order to develop, build, test and release our changes. The release of changes and versions occurs when we commit changes to a codeline, transfer changes between codelines, baseline a configuration, or promote a configuration to a new promotion-level. Based on this, we already know a few things about change granularity:
- The granule of change is not an individual file/checkout, but is rather a single development task that holds changes we then commit to the codeline.
- The granule of baselining and promotion is not an individual change but is, instead, the unit of integration for building and testing the component or product undergoing change on the codeline, which is the configuration.
- The granule of progressive collaboration and evolution is the codeline
Not all of the above require principles. Furthermore it’s not apparent that each of these three OOD principles will translate to individual version control principles. Instead, we want to see if we can apply these three principles together as a group for each of changes, baselines, and codelines.
Package Coupling - Change-Flow