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: Configuration Status Accounting: Identify data file(s) and document representations of revisions/versions of each document/software delivered, or made accessible electronically
Finally, on page 5-19 (citing ASME Y14.55M):
Revisions to Drawings
- Drawing revision identification
- Any change to a drawing, including a change to Rights-in-Data, must be recorded in the revisions block of the affected drawing.
- Record revision status, identification of change authorization documents, or description of changes, and change approvals, and if multi-sheet, revision status of sheets
MIL-STD-973 has some interesting contextual definitions:
3.70 Notice of Revision (NOR) . A document used to define revisions to drawings, associated lists, or other referenced documents which require revision after Engineering Change Proposal approval.
188.8.131.52.4 Consolidation of multiple changes into a single unrelated ECPS may be combined into a single revision to a document provided that:
a. All changes apply to the same end item.
b. All changes apply to the same revision/version...
184.108.40.206 Software identifiers. For each CSCI, the contractor shall identify its corresponding Computer Software Components (CSCs) and Computer Software Units (CSUs). For each CSCI, CSC, and CSU the contractor shall issue/obtain a software identifier, which shall consist of a name or number, and a version identifier, and shall relate the software to its associated software design documentation; revision; and release date. The contractor shall embed the software and version identifiers within the source code, and provide a method for display of the software and version identifier data to the user upon command.
EIA-649-1998: The EIA committee also didn't feel the need to explicitly define revisions, but uses the term throughout the standard:
configuration identification: ...(3)...maintain[s] document revision relationships to product configurations.
Methods of identifying documents...includes at least...organization, a unique identifier..., and a revision indicator (number, letter, or date).
A version is defined using the MIL-HDBK-61A description.
ISO 10007-1995, 7.4.1 has only one reference to "revision", and no reference to "version":
...All change proposals should be documented and should typically include the following information prior to their submission to the CB:
- configuration item(s) and related documents to be changed, name(s) and revision status; ...
Since DOD-STD-2167A specifically addresses software development, it isn't surprising that "version" is used for a software variation:
3.34 Version. An identified and documented body of software. Modifications to a version of software (resulting in a new version) require configuration management actions by either the contractor, the contracting agency, or both.
But it is interesting that changes to DOD-STD-2167, as a document, are considered revisions:
6.5 Changes from previous issue. Asterisks or vertical lines are not used in this revision to identify changes with respect to the previous issue due to the extensiveness of the changes.
The IPC-257x standards for defining Product Data eXchange (PDX) files offers both revision (productRevision) and version (versionIdentifier) for parts, but only describes versions for electronic file attachments. While the IPC standards don't offer any distinction directly, revisions have somewhat superior standing; for instance, an item change history includes "oldRevision", "newRevision", "proposedRevision", "minimumShippableRevision" but there's no equivalent for versions. Likewise, (although we discourage it for other reasons) engineering changes are permitted to have revisions, but not versions.