Revisions & change control
Hardware Revision Control: A Practical Guide for Electronics Teams
Why hardware needs its own approach, what freezing actually means, a five-rule process, and a worked example over eighteen months.
Topic
Revisions, releases, baselines and engineering change.
Revisions & change control
Why hardware needs its own approach, what freezing actually means, a five-rule process, and a worked example over eighteen months.
Revisions & change control
Nine changes over two years, three of which need new bare boards. A worked progression, a decision table, the edge cases, and the one rule that settles most of them.
Revisions & change control
A change to a design is never a change to one file. An impact map by change type, a checklist by artefact, and the three questions that catch the expensive misses.
Revisions & change control
Four questions for day one, an inventory for week one, the knowledge that is in nobody's files, and how to reconstruct a project when the engineer has already gone.
Revisions & change control
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.
Revisions & change control
Request, decide, tell. One change followed end to end, what each document should contain, and the one-page version a small team can really sustain.
Revisions & change control
Your files stay editable after release, so a baseline is a promise rather than a lock. What goes in one, the three ways teams freeze, and the smallest version that works.
Revisions & change control
Commit sources, generate everything else — plus the release exception, what Git genuinely gives hardware, what it cannot do, and where the boundary falls.
Revisions & change control
Rank your evidence before you read any of it, start from a physical board, ask who kept copies, and write down what you could not establish.