our SCM or version control tool. There are a multitude of different implementations that occur in practice, and different tools seem to support or even prefer some implementation approaches more strongly than others. The items undergoing the promotion range from versions to workspaces, branches/codelines, and labels/tags. The most commonly recurring patterns are as follows:
- Version promotion (promoted versions)
- Promotion workspaces
- Branch promotion (promoted branch)
- Promotion branches (promotion branching)
- Label promotion (promoted label)
- Promotion labels (promotion labeling)
Version Promotion (Promoted Versions)
This may be the best known of the promotion implementation approaches. It was popularized by some of the earlier version control tools like CCC and PVCS. Individual file versions are assigned attributes corresponding to their promotion level. For example, if our promotion levels were titled “Private”, “Team”, “QA”, “Customer”, and “Failed” then each file version would be associated with at most one of these promotion levels. When a set of versions progressed through a new promotion milestone, those versions would be promoted to the next level by changing their promotion-level attribute to the next value in the progression (e.g., from “Private” to “Team”, or from “Team to “QA”). In theory, every time a file is checked-out and then back in, it starts over again at the initial promotion level. So you can always tell which files on the tip of the codeline are fresh and which ones are more mature.
You can also easily discern if all the files on the tip of the codeline are all at the correct promotion level prior to releasing. This seems fairly straightforward, and some version control tools assume this particular approach and make it available “ut of the box. If you have to implement it yourself though, it can be cumbersome to apply/update the attribute for all affected versions, or to even identify all the affected versions. Some would also argue it can be confusing to keep track of which versions are the current ones to use.
This is quite possibly the oldest of the promotion implementation approaches, dating back to when source-code version control and related tools were in the stone age and a version control tool was only slightly more than a backup/restore mechanism. One of the earliest published examples is from the IBM OS 360 project  where source-code libraries were stored in so-called vaults: one for development, another for integration/test, and a third for release/distribution.
In more modern times, a workspace (or sandbox) would be used to represent several of the promotion levels, especially those that corresponded to a distinct level of integration and test. Code would be promoted by merging it and checking it in to the next promotion workspace in the progression. This approach is also straightforward, and doesn’t have the drawback of having to apply a named promotion level attribute to every version. It does suffer the overhead of having to copy/merge versions from workspace to workspace, often even if not all the versions changed.
Furthermore, workspaces aren’t necessarily first class entities in a version-control system, so it may be difficult to know what promotion-level a version corresponds to without knowing which promotion workspace it came from, and whether or not the other promotion workspaces have the same or different version of that file. Promotion workspaces are often well-suited for promotion levels that correspond to distinct levels of integration and/or ownership, particularly when combined together with some of the other approaches. For example, it can sometimes make sense to have a separate branch and workspace for a particular promotion level
Branch Promotion (Promoted Branch)
Branch promotion is when a set of promotion levels applies to a particular