You know the folder. It lives on a shared drive or buried in an email thread, and it looks like this: board_v2.zip, board_v2_fixed.zip, board_final.zip, board_final_v2.zip, and the crown jewel, board_final_v2_REALLY_final.zip. Somewhere in there is the design you actually sent to the fab. Probably. You think.
Every hardware team has this folder. It's the folder of doom, and it's where traceability goes to die. The problem isn't that you're disorganized — it's that zip-by-email was never a release process. It's a filing cabinet with the labels torn off.
Hardware needs real, versioned releases: immutable snapshots you can trust, reproduce, and hand to anyone. Not archaeology.
Why zip-by-email fails
A zip file has no authority. It's a bag of bytes with a name someone typed while tired. That creates specific, expensive failure modes:
- Which revision got fabbed? Six weeks later a batch comes back with a footprint problem. You open the folder. Was it
final_v2orfinal_v2_REALLY? The timestamps lie because someone re-saved to fix a typo in the readme. - Which BOM matches which Gerbers? Nothing in a zip guarantees the Gerbers, the BOM, and the pick-and-place file were all exported from the same design state. You export Gerbers Monday, tweak a value Tuesday, export the BOM Wednesday — and now your fab is placing a part that isn't on the board.
- No single source of truth. When the canonical version is "whichever zip Dave last emailed," every question about the board becomes a group chat.
None of this is a KiCad problem. KiCad will happily export perfect Gerbers all day. The gap is that nobody told the outputs which revision they belong to.
What a proper hardware release actually is
A release is an immutable snapshot. Say it out loud, because both words matter.
Snapshot: it captures one exact revision of the design — this commit, these schematic and PCB files, frozen — together with everything generated from it: the Gerbers, the drill files, the BOM, the CPL/pick-and-place, the DRC and ERC reports, the 3D render.
Immutable: once you cut it, it never changes. If you need a fix, you make a new release. You never reach back into rev-C and quietly swap a file. That single rule is what makes a release trustworthy: rev-C means the same thing to you, your fab, and your client, forever.
The key insight is that the outputs are derived from and bound to the revision. You don't store a BOM that happens to be lying next to some Gerbers. You store the BOM that was generated from commit a3f9c1, alongside the Gerbers generated from that same commit. They can't drift apart because they were born together.
The final_v2.zip way vs a real release
final_v2.zip way |
A real release | |
|---|---|---|
| Identity | A filename someone typed | A tagged revision (e.g. rev-C, commit a3f9c1) |
| Outputs | Loose files, exported whenever | Gerbers, BOM, CPL, DRC/ERC all from the same commit |
| Can it change? | Yes — anyone can re-save it | No — immutable once cut |
| "Which one shipped?" | Guesswork from timestamps | Exact, recorded, unambiguous |
| Reproducible? | Only if you kept the right files | Always — regenerate from the tag |
| Handoff to fab/client | Attach zip, hope | Share one link to the frozen snapshot |
| Six months later | Filename archaeology | Open the tag, everything's there |
How to run revisions and releases for KiCad
The good news: KiCad files are plain text, so this is entirely doable with tools you already have.
1. Put the design in Git. Commit your .kicad_sch, .kicad_pcb, and .kicad_pro. Now every change has a history, a diff, and an author. This alone kills the "which zip?" question — the design has one authoritative timeline.
2. Work in the open, tag when you're ready. Day to day, you commit freely. When a revision is manufacturable, you tag it — rev-C, or v1.2.0, whatever your scheme. That tag is the pointer to an exact, permanent commit.
3. Generate outputs from the tag, not from your working tree. This is the part people skip, and it's the whole point. kicad-cli can export Gerbers, drill files, BOM, and more straight from the command line, no GUI. Run it against the tagged commit and every output is provably tied to that revision. Bundle them and you have a release.
Do it by hand and it's a checklist you'll eventually rush. That's exactly the automation GoForFab handles for you — more on that below.
"Working" vs "released": two different states
A lot of confusion disappears once you separate these:
- Working state is your live design. It changes hourly. It's allowed to be broken, half-routed, and experimental. Nobody manufactures from working state.
- Released state is a decision. You've looked at a specific revision, run your checks, and declared: this one is real. You freeze it. Its outputs are locked to it.
The mistake is treating them as the same thing — fabbing straight from whatever's open in the editor, then trying to reconstruct later what that state was. Releases exist precisely so that "what we manufactured" is a recorded fact, not a memory.
Traceability is a gift to three people
Your future self. The board comes back, something's wrong, and it's now three projects ago. With releases, you open rev-C and see the exact files, outputs, and reports that produced that batch. No detective work.
Your fab. When the Gerbers, drill, and CPL demonstrably come from one revision, you've removed an entire category of "the placement file doesn't match the board" back-and-forth. One coherent package, one link.
Your client. "We shipped you rev-C, here's the immutable snapshot" is a fundamentally different conversation than "let me find the right zip." It's the traceability people assume you need an expensive enterprise suite to get. You don't — Altium's data management is genuinely excellent at this, but a disciplined tag-and-generate workflow gets a small KiCad team the same trustworthy result without the license.
Make every push a real release
Here's the soft sell, and it's an easy one. Doing releases right by hand — tag, check out clean, run kicad-cli for every output, bundle, store, share — is a discipline that erodes the moment you're in a hurry. That's how the folder of doom grows.
GoForFab turns it into something you don't have to think about. Connect your KiCad project, and every push produces a clean, shareable, reproducible release automatically: the full output set — Gerbers, BOM, CPL, DRC/ERC, 3D — generated with kicad-cli from that exact revision, frozen, and given a link you can hand to your fab or your client. No zip. No archaeology. And it's free forever to get started.
For more on the workflow underneath, see how Git version control fits a KiCad project — the foundation that makes real releases possible in the first place.
Delete the folder of doom. Your future self is begging you.