PCB data management

PCB revision control: stop manufacturing the wrong hardware version.

PCB revision control is not paperwork for large companies. It is how a freelancer, startup, or small electronics team prevents old Gerbers, mismatched BOMs, and wrong firmware from reaching the manufacturer.

PCB revision control workflow with board design, BOM, firmware, and manufacturing release documents
Every PCB revision should connect the design files, exported manufacturing files, BOM, firmware version, test notes, and release reason.

Direct answer: what good PCB revision control looks like

Good PCB revision control means every released hardware version has a unique revision name, a frozen manufacturing package, a matching BOM, compatible firmware, release notes, and a record of what changed. Use names like `HW-R1_prototype`, `HW-R2_pilot`, and `HW-R3_production`. Never send a Gerber zip, BOM, or firmware build without knowing which hardware revision it belongs to.

Why PCB revision control matters

In software, the wrong version can often be patched. In hardware, the wrong version becomes copper, solder mask, assembled components, inventory, shipping delay, customer returns, or field repair confusion.

Fabrication Wrong Gerbers sent

The PCB fab manufactures an old board outline, wrong connector location, or unfixed footprint.

Purchase Wrong BOM ordered

The purchase team buys parts for R1 while engineering expects R2 components.

Firmware Wrong build flashed

A firmware build uses old pin mapping, sensor address, boot behavior, or calibration constants.

Simple PCB revision naming system

The best revision naming system is boring, consistent, and easy to understand under pressure. Avoid `final`, `new`, `latest`, and `client-sent`. Those names collapse as soon as one more change happens.

Revision Use when Example release folder
HW-R1 First prototype board or first customer sample. `HW-R1_prototype_2026-06-06`
HW-R2 Second board after layout, connector, BOM, or bring-up changes. `HW-R2_pilot_2026-07-18`
HW-R3 Production-ready or field-fix revision after validation. `HW-R3_production_2026-09-02`
Variant suffix Same product with connector, power, region, or enclosure variant. `HW-R2A_12V_variant_2026-07-20`
Important

Use the same revision name on the PCB silkscreen, schematic title block, BOM filename, Gerber zip, firmware release note, and test record.

What belongs in a controlled PCB release

A revision is not only the editable PCB file. A controlled release is the whole package that another person can use to fabricate, assemble, test, or support the board.

  • Editable schematic and PCB source files
  • Gerber zip and drill files exported from the approved layout
  • BOM with MPNs, footprints, quantities, alternates, and DNP notes
  • Pick-and-place file for assembly
  • Assembly notes with polarity, jumpers, and hand-soldering instructions
  • Firmware version or build compatible with this hardware revision
  • Bring-up checklist and production test steps
  • Release notes explaining what changed and why

Link BOM and firmware to the PCB revision

A PCB can be electrically correct and still fail because the wrong part or wrong firmware was used. Revision control must include the BOM and firmware, not only the board files.

Item Must be linked to revision because Example failure
BOM Components, footprints, values, alternates, and suppliers can change. Assembly uses a regulator footprint from R1 on an R2 board.
Firmware Pins, peripherals, boot behavior, calibration, and configuration can change. Firmware expects relay on GPIO25, but R2 moved it to GPIO26.
Test procedure Power rails, jumpers, LEDs, connectors, and limits can change. QC fails good boards because the test sheet is for the old revision.

Minimum change workflow for small teams

You do not need enterprise PLM on day one. But you do need a lightweight process before the wrong revision costs real money.

1 Open a change note

Record the problem, request, customer feedback, manufacturing issue, or part change.

2 Update design and BOM

Make the schematic, layout, BOM, and firmware changes under the next hardware revision.

3 Review release files

Check Gerbers, drills, BOM, pick-and-place, assembly notes, and test notes together.

4 Freeze and archive

Mark the release as approved, sent, superseded, or production-active.

Folders, Git, PCB Vault, or Electronics PDM?

Different stages need different tools. Do not overbuild process too early, but do not wait until production mistakes become normal.

Stage Good enough tool When to upgrade
Solo project or first prototype Clean folder template and disciplined naming. When you have multiple clients, vendors, or releases.
Freelance PCB work PCB Vault Software for files, BOMs, Gerbers, and releases. When approvals, purchase, firmware, and production need control.
Small electronics team PCB Vault Software Team or lightweight PDM workflow. When ECOs, audit trail, component lifecycle, and release gates matter.
Manufacturing product team Electronics PDM. When product data must connect engineering, purchase, production, QC, and support.

Start simple, but make every release traceable.

Use the free folder template if you are still organizing manually. Use PCB Vault Software when releases become hard to track. Move toward Electronics PDM when approvals and audit history become business-critical.

FAQ

What is PCB revision control?

PCB revision control is the process of tracking hardware changes across board files, Gerbers, BOMs, firmware, test notes, and manufacturing release packages.

Is Git enough for PCB revision control?

Git is useful for technical file history, but it does not automatically manage manufacturing releases, BOM approvals, vendor handoff, purchasing context, or production status.

Should PCB revision be printed on the board?

Yes. A visible hardware revision on the PCB silkscreen helps production, support, repair, and field troubleshooting identify the board version quickly.

When should a PCB revision number change?

Change the revision when the schematic, PCB layout, footprint, connector, BOM-critical part, test procedure, or firmware compatibility changes in a way that affects manufacturing, assembly, or support.