Terminology: revision or version?
Describing an item's evolution
Since traditional configuration management literature does not commonly use the term "variation", we use it here to describe an item's evolution in a general way, regardless of whether such an evolution requires releasing a formal revision or a new inventory part number. For instance, changing an item's lifecycle phase from prototype to production may not represent any change to the item's design or production documentation, or to the related part's form, fit or function. Alternately, a part modification may require that a new identifier be assigned, as the new part is not interchangeable with the previous part.
In any case where we may need to refer to before/after attributes of an item, but without regard to whether the item identifier or revision has changed, we need an abstraction like variation.
"Revision" is the most widely-used term for referring to that attribute which distinguishes one closely-related design variation from another. A revision represents a change to a document's contents, or a modification to a part such that the part remains interchangeable with its previous variation.
Based on our assessment of the available literature (below), "version" is a disfavored general term, only applicable for narrow purposes related to iterating software releases.
We treat a version as an optional alias for a revision. While item revisions typically identify discrete steps in the evolution of an item, versions often are not sequential. Versions are commonly used for computer program files to identify
a specific set of features,
a set of bug fixes, and/or
a particular build number.
For example, a version "1.2.403" may indicate the marketing feature set "1.2" plus the compiler build "403". While you have a very good feel for how many releases are represented in going from revision "AA" to "AD", you'd have little idea whether there were a few releases, or several hundred, between versions "1.2.403" and "2.1.1042".
The reason that we need an alias is that competing data management processes may create their own variation identifiers. A PLM system can provide a sequential revision "overlay" to the software developer's seemingly-arbitrary, and generally non-sequential, version.
And, given the wider role for revisions in the IPC standards, we would propose that you cannot have a version without also specifying an associated revision.
Except in specialized cases, there's little general support for using the term "variation".
Iteration describes the unique combination of an item's particular revision at a specific lifecycle phase.
MIL-STD-100 only uses "version" (once) to refer to a part. Based on the context, we believe that the more appropriate term would be "variation":
406.13 Change requiring new identification. When a repair part within an item is changed so that it is no longer interchangeable with its previous version, it shall be assigned a new PIN.
The term "revision" is used extensively. As an example:
The CAGE Code, drawing format size letter, and drawing revision letter are not considered part of the drawing number.
MIL-HDBK-61A, interestingly, seems there was no need to actually define the term "revision", though its meaning is presumed by context:
Configuration baseline (baseline). (2) An approved and released document, or a set of documents, each of a specific revision;...
Notice of Revision (NOR). A document used to define revisions to configuration documentation which require revision after Engineering Change Proposal approval.
However, a version is explicitly defined
(1) One of several sequentially created configurations of a data product.
(2) A supplementary identifier used to distinguish a changed body or set of computer-based data (software) from the previous configuration with the same primary identifier. Version identifiers are usually associated with data (such as files, databases and software) used by, or maintained in, computers.
And, reinforcing that documents have revisions while software has versions (pg 4-34):
ACTIVITY: Configuratio