“We’ll build it like last time, but better.”

— A doomed engineer

By XKCD, a really funny and creative cartoonist

Why versioning matters now more than ever

In software, version control is a solved problem. Git, semver (semantic versioning), automated checks, and CI/CD (continuous integration/continuous deployment) pipelines have made iterative development not just feasible but fast, safe, and scalable.

Hardware is… not there yet.

Versioning in hardware design is like leaving a breadcrumb trail in a tornado. Between ECAD tools, contract manufacturers, firmware engineers, and test jigs, what constitutes a “version” depends entirely on who you ask.

But this isn’t just an academic problem. A mismatch in versioning can lead to wasted labor, failed field tests, dangerous products—and in worst-case scenarios, real human harm.

Let’s unpack what versioning actually is in hardware, where things go off the rails, and how better systems (and a little Git) can make design safer, faster, and more collaborative.

What is versioning, really?

Versioning is the act of labeling a specific state of a design so it can be built, discussed, tested, and reproduced.

But hardware complicates this:

• PCBs are often tracked with integers: Rev A, Rev B, R14.
• Firmware uses semver: v1.3.12.
• Assemblies get nebulous: are we tracking the BOM? The ECAD files? The barcode on the board?

And what about design readiness stages like P0, DVT, or P1? Are they versions? Labels? States?

The answer is yes—and also no. They represent intent rather than design state. That’s the root of the confusion.

Design readiness vs. versions

Design readiness terms—EVT, DVT, PVT, MP—are lifecycle stages, not revisions. They reflect the product’s maturity, not what’s in the file. You can have:

• DVT Build #1 using PCB R3
• DVT Build #2 using PCB R4A and firmware v1.3.1

Without clearly versioning the subcomponents, the term “DVT” becomes ambiguous.

Assemblies are the wild west

Assemblies are often the melting pot where all this goes wrong.

• Firmware v1.4.0 is flashed onto PCB Rev B
• But the BOM was pulled from the “latest” Excel file
• And the label says “Ornithopter Left Wing Driver – P1”

There’s no consistent fingerprint. When the unit fails, there’s no trail of breadcrumbs—just blame.

What happens when you get versioning right

Good versioning doesn’t just prevent catastrophe. It unlocks speed, modularity, and resilience.

🚀 Smooth and fast design cycles

When your Git tags match what’s built, you can:

• Run async design reviews
• Automate DRC/ERC checks
• Integrate with CI for BOM linting, diff tools, or schematic integrity

No more waiting on email attachments and “final_final_rev2.zip”.

🧱 Modular reuse without guesswork

Need to re-use a validated power supply block? If it’s tagged, documented, and versioned, you can.

Modularity dies in ambiguity. Versioning resurrects it.

📎 Linked documentation and procedures

Imagine if every CM had a QR code to a release note, test procedure, and bill of materials for that exact version—not the last one someone remembered to email.

What happens when Electrical Engineers get versioning wrong

“Just this once” versioning feels like a treat. Until it kills you.

🧨 The stakes for Electrical Engineers

Minor inconvenience: The LED doesn’t turn on.

Wasted labor: 200 units assembled with the wrong BOM.

Field failures: Firmware can’t detect sensor due to PCB change.

Destruction: A power supply oscillates and fries surrounding systems.

Injury or death: Critical timing mismatch in medical or automotive systems.

🤹 Multiple versions in parallel

Ever seen a CM build from an old Gerber and a new BOM?

Or a unit labeled “P1” but the firmware log shows “v1.4.9-patch”?

You’re not alone. But that’s how errors slip through.

The price/flexibility/quality triangle

Here’s the hard truth: low cost often means low margin for error.

• You quote 3 vendors for price.
• The lowest shifts your build to a less-experienced night team.
• They’re handed files named “new_final” and a BOM with no hash.

The result? A literal gamble. You got a better price, but it cost you control.

This doesn’t mean you shouldn’t negotiate. But if you’re changing files fast and loose, you need systems that make your vendors more bulletproof.

Why version control breaks down in hardware

Because people don’t agree on what’s the thing being versioned.

Every stakeholder has their own system:

Role	How They Refer to Versions
CM	“The new rev from the customer”
Firmware	“v1.21.002 LED update”
Planner	“PN-004942 P1”
EE	“PCB942-R12C”
Test	“TEST_137-LED-D34.zip”
Review	“August Update”

Multiply that by multiple SKUs, sites, and schedules—and versioning becomes entropy, and it’s only going to get worse. That’s the law (2nd law of Thermodynamics )

(entropy in the form of “new_final_FINALb.zip”)

What different hardware development stakeholders need

Understanding needs is the first step to consistency.

• Contract Manufacturers (CMs)
  • Want: short part numbers, infrequent changes, clear instructions.
  • Hate: mystery zip files and silent BOM updates.
• Firmware teams
  • Want: clear mapping of hardware changes to firmware behavior.
  • Hate: discovering connector changes after flashing.
• Planners
  • Want: ERP and PLM compatibility.
  • Hate: hand-edits to PDFs and emails with “ignore the filename”.

Types of versioning in the wild

Ad-hoc

• Sharpie on PCB
• “Latest” folder in Dropbox
• CM creates their own filename which can differ during a run or between build runs.

Alpha + Integer

• Rev B, V1A, R3C

Human-readable. But hard to parse, easy to reuse inconsistently.

Semver for Hardware?

Semantic versioning, inspired by software:

• Major: Breaking changes (mounting holes, connectors)
• Minor: Non-breaking electrical changes (IC swap, layout cleanup)
• Patch: No

Semantic, but only works if rigorously followed. Even with the best design intents, the person running your board through the PCB might not understand the difference between 1.32.7-1 and 1. Semantic versioning works well for the people it works well for and is confusing and dangerous for people who don’t understand it.

Change logs should be useful.

Versioning in the wild

Here are some quotes from engineers in the wild about their approach to versioning.

“So I’ve always done numeric major rev’s for pre-release boards, letter revs once a board has been RTM. PCB is built into the copper, PCBA noted in silkscreen.

The logic my teams have used is that once it leaves the engineering group, the version should be indelible, you can always approve another change order if something is wrong.”

“I’ve been a circuit board designer for over a decade, and my take on semantic versioning for PCBs is like this:

v1.2.3

• the Major version (1) indicates Mechanical compatibility. This gets incremented when a PCB change requires the housing to be updated as well
• the Minor version (2) indicates Gerber file compatibility. This gets incremented whenever the PCB design files change and a new version of the PCB must be ordered
• the Patch version (3) indicates BOM compatibility. This gets incremented whenever the BOM changes, without changing the PCB itself (changing resistor values, setting components to DNP, etc)

I like this system because it gives you a consistent way to understand what other parts of the system maintain compatibility with this specific PCB version.”

Git as a versioning backbone

Git isn’t just for software. Git has great features that help electrical engineers get control of their designs and releases.

• Tags & releases map to builds and specific snapshots of your design
• Pull requests serve as design reviews, giving every stakeholder the chance to review the design and the version labels.
• Access control limits what’s shared (assembly vs. source files).
• No email attachments means no outdated files in circulation.

AllSpice’s Git-native platform brings this rigor to ECAD, linking design intent, review, and release all in one flow.

🧠 A hybrid future: smart, flexible, verifiable

If there’s no single versioning system that works for everyone, what are we supposed to do? How do we speed up our design cycles, keep costs low, and not introduce fatal ambiguity into our hardware releases?

The answer lies in embracing the chaos—but doing it with structure. Interoperability is the future. We don’t need one rigid system. We need many small, cooperative ones that speak a common language.

This is already happening, and the best teams are moving toward hybrid systems that blend traceability, automation, and real-time feedback across the stack.

🧾 Barcodes with Semver + integer IDs

Start with the literal foundation—your PCB.

• Silkscreen-printed barcodes should encode the base PCB revision (e.g., R3C) and align to your internal tracking system. This is non-negotiable in a modern traceability chain.
• Leave space for additional barcode labels applied post-assembly:
  • One for the specific BOM population (e.g., resistors swapped, optos removed for debug).
  • One for the firmware version flashed onto the board.
• Use a standard 2D format (like DataMatrix or QR) so contract manufacturers and test stations can scan them without custom readers.
  • 2D Datamatrix standard for traceability
• Bonus: Create composite IDs—something like PCB-R3C+BOM-7F2+FW-v1.3.5—that encode the full context of the unit on the bench. This becomes the fingerprint of your physical release.

🧩 Your number + their number. Everyone’s happy, and no one builds the wrong thing on a Friday at 11:42pm.

🤖 Automated checks + releases

Versioning errors often come from human shortcuts—like someone zipping the wrong folder or editing a spreadsheet without updating the filename. Automation is the antidote.

• Integrate automated checks into your design release workflow:
  • Mismatched BOM and schematic? Fail the check.
  • New footprint without updated stencil? Raise a flag.
• Use Git tags + release gates to freeze golden versions.
• Automatically generate issues or tasks when changes are made to production files without corresponding documentation updates.
• Add version plan checklists to pull requests and reviews to catch inconsistencies before they hit production.

These checks don’t slow you down—they speed you up by catching the mistakes before they cost you time and material.

📶 Connected test & inspection

Testing isn’t just about passing or failing—it’s about feeding back what happened in the real world.

• Hook up test stations to cellular or networked connections to stream real-time metadata to your Git history or MES system.
  • Each unit gets its barcode scanned before test.
  • Results are logged against the exact version of hardware and firmware under test.
• Use live dashboards to monitor product yield and raise alerts when deviations hit thresholds. Every article is a first article.
  • For example: flag if 8 of the last 50 units failed LED alignment.
• Trigger real-time alerts:
  • Notify the manufacturing lead via email or SMS if a test jig is used on an unsupported revision.
  • Pause the line if firmware doesn’t match board barcode.

By closing the loop between test and design, you go from “hope it works” to “know it does.”

(Smart factories and real-time feedback)

🔁 Tight design feedback loops

When your release and manufacturing systems talk to each other, your design loop shortens—and that’s where the real ROI lives.

• Bugs are caught earlier.
• Field failures become traceable.
• Revisions shrink in scope and frequency.

Instead of giant quarterly “Rev C” updates that patch 19 unknowns, you can roll micro-releases safely and verify their impact.

This is how high-performing teams build safer, smarter hardware without sacrificing speed.

Let’s talk about your versioning pain

Git-native workflows for ECAD

AllSpice helps teams unify ECAD design, review, and release—all through Git-native workflows that play nice with your tools, processes, and teams.