The purpose of version numbering is to identify different releases, with the aim of finding back the exact code corresponding to any version.
In principle you'd be interested in:
- versions that could still be in use somewhere (either the software was sent outside the company, or inside the company to another department and hence no longer under the control of the product development team).
- versions that work well, so that if some changes would really screw the things up, you could still go back to the last reliable version, and ship it if needed.
So if a version passed a successful testing process, you'd be in the second case. Hence a version number would make sense, event if it's an internal release.
More formal approach
If you apply Semantic Versioning, the criteria for versioning is still the release:
- Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a
It's not explicitly said if it's internal or external release, but both should be assumed. Because development versions are in principle not external releases:
- Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Now the SemVer standard allows some liberty in the numbering scheme for pre-releases:
- A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.
It also allows to keep one version number shared between several different builds:
- Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.
So the question here is not so much what distinguishes an internal from an external release, but what distinguishes a build from a release.
In the end, same conclusion as previously: a version that successfully passed a successful testing process deserves to be well identified. If you don't want to follow build numbers in your source control system, then a proper version number should be used.