Revisions & change control
Version, Revision, Release, Baseline: Four Words, One Object
No authority settles these words, so two people can agree and mean nothing. How each is commonly used, where they collide, and how to make yours unambiguous.
"Which version are you on?"
"Version 2."
Two people have now agreed on something, and there is a decent chance they agreed on nothing at all. One meant the second iteration of the design. The other meant the second batch built. A third person in the room would have assumed the second released configuration, which is neither.
Hardware vocabulary has four words that circle the same object — version, revision, release, baseline — and no authority that settles them. What follows is not a ruling on which definitions are correct. It is a description of how each word is commonly used, where the collisions happen, and how to make your own usage unambiguous, which is the only outcome available.
The four words as most people use them
Version is the loosest. It usually means "an identifiable state of a thing", at whatever granularity the speaker has in mind. Because it is loose, it is the word most likely to be misunderstood, and the one worth avoiding when precision matters.
Revision usually means a specific, identified state of a specific deliverable: this schematic, this board, this document. Revisions are typically sequential and small-grained. Rev A, Rev B, Rev C.
Release usually refers to an event rather than a state: the moment a set of things was declared fit for a purpose and handed over. You release Rev C to manufacturing. The release is what happened; Rev C is what was released.
Baseline usually means a set: a group of items, each at a stated revision, frozen together as a known configuration. "Baseline 2.1 is PCB Rev C, BOM Rev 4, firmware 1.2.7, enclosure Rev B."
Those are tendencies, not rules. In a regulated supplier they may be formally defined; in a four-person team they may float. Both can work. What does not work is two people in the same room using the same word for different things.
Where they collide
| Phrase | One reading | Another reading |
|---|---|---|
| "the latest version" | newest file on disk | newest released configuration |
| "v2" | second design iteration | second product generation |
| "revision 3" | third revision of the board | third revision of the BOM |
| "released" | sent to the fabricator | formally approved |
| "current" | what we are designing | what we are shipping |
| "the new board" | the one on my bench | the one in production |
Every line of that table has cost somebody a build. "The latest version" is the worst offender, because the newest file is very often not the released one, and both speakers assume theirs is the obvious reading.
Where the words come from
Part of the confusion is that the vocabulary arrives from several directions at once, and each source brings its own habits.
ECAD tools version files. Their natural unit is a document, and their numbering often belongs to the tool rather than to your product.
ERP and purchasing systems version part numbers. Their natural unit is a buyable item, and they often resist the idea that an item has internal structure at all.
Software practice brings semantic versioning — major.minor.patch — which encodes compatibility. It transfers to firmware cleanly and to hardware badly, because "backwards compatible" is a much slipperier claim about a physical object.
Quality standards bring configuration-management language, where baseline and change control are precisely defined, and where "version" barely appears.
None of these is wrong. They are simply four vocabularies meeting in one project, which is why the words slide.
Decide, write it down, stop arguing
The useful move is not to find the correct definitions. It is to write down yours, in one short paragraph, where people will see it.
Something like:
Revision applies to a single item: a board, a BOM, a document. Letters for boards, numbers for BOMs. Release is the act of approving a set of items for a purpose; a release produces a baseline, which names every item and its revision. We do not use the word version in engineering documents.
That last sentence is the one that does the most work. Retiring your vaguest word costs nothing and removes most of the ambiguity in one stroke.
A naming scheme that survives contact
Whatever words you choose, the identifiers themselves should be decodable by someone who was not there:
Distinct symbol sets per level help. Letters for the bare board, digits for the assembly, and the two written together: Rev C-2. Avoid pure dates as identifiers. 2025-03-14 tells you when, not what, and two things can be released on one day. Avoid reusing a retired identifier, ever. If Rev B was scrapped before it was built, skip to C. A reused letter will eventually be believed. Avoid internal-only codes on anything that leaves the building, unless they are also written somewhere a stranger can look them up.
The test is simple: hand your identifier to someone outside the team and ask what it tells them. If the answer is "nothing, I would have to ask", the scheme is working only because the people who hold the key are still employed.
One sentence worth adding everywhere
On every document and every package, write the thing in full:
This document applies to PCB Rev C, assembly Rev 2, released 14 March 2025.
Long, unglamorous, and it ends an entire category of conversation. The words you chose stop mattering once the identifier carries its own interpretation.
Terminology is only half of it. The other half is having one place where the agreed revision of each item actually lives, so that "Rev C" resolves to the same data for everyone who looks it up.
In XKEMA each board and each BOM carries its own version history, and every version records who created it and when.
Hardware revision control Hardware revision control: a practical guide * PCB revision vs assembly revision