What is an interim version in Source Control?

Question

I've been working on an open source project recently and have been checking out Core Infrastructure's best practices checklist.

One of the items pertaining the "Change Control" checklist is as follows:

To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases.

This confused me as to what "interim versions" are, objectively. Looking up "interim version" in different contexts never yielded me anything besides a broad term of "intervention", which makes sense but returned no real examples of.

Does the classic git workflow where we have automated checks, PRs, code reviews and a development branch count as a form of interim? Or are they something else, that need to be tagged in version control as their own version?

Answer 1

The introduction at the top of the criteria for that initiative includes this sentence:

For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different organizations.

The mention of "review" is repeated in the repo_interim criterion:

To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases.

Changes are much easier to review when they are broken down into small, individually-described, pieces. So allowing someone to view the log of changes you made to a project is an important part of leaving it open to review.

Some open source projects do not allow access to their internal development process, instead releasing each completed version along with its source code. This requirement is making clear that posting a snapshot of each release to a public repository is not sufficient, even though it would meet the repo_public criterion:

The project MUST have a version-controlled source repository that is publicly readable and has a URL.

For example, a repository which had only "final releases" might look like this:

af564c2  Snapshot version 1.0
bc459aa  Snapshot version 1.1
affe00a  Snapshot version 1.2
004bac2  Snapshot version 2.0

Whereas a repository which made the public development history available would have additional commits, more like this:

ab98c24  Release version 1.0
be564c3  Worker vomit now work when someone walk on the cloud
ae459af  Elbows should only bend in certain, expected, ways regardless of what T-Shirt you are wearing.
29fe005  Release version 1.1
99e5bc1  Players eyes now reflect how drunk they are
664bac1  Release version 1.2

(Sample commit messages courtesy of The Strange Log)

This is more than just publishing the log of the changes, as anyone looking at the repository can check out, say, commit ae459af. This is an "interim version" in the sense that it's a state of the application somewhere between release 1.0 and release 1.1.

This is also important to the "right to fork": if the elbow fix was controversial, someone could check out the "interim version" of the application in commit be564c3 and create their own release. If they only had access to the 1.0 and 1.1 source code, this would be harder to do.