{"id":1915,"date":"2026-09-27T13:21:44","date_gmt":"2026-09-27T13:21:44","guid":{"rendered":"https:\/\/www.diyipcb.com\/pcb-revision-control-prototype-to-production\/"},"modified":"2026-09-27T13:21:44","modified_gmt":"2026-09-27T13:21:44","slug":"pcb-revision-control-prototype-to-production","status":"publish","type":"post","link":"https:\/\/www.diyipcb.com\/es\/pcb-revision-control-prototype-to-production\/","title":{"rendered":"Control de revisiones de placas de circuito impreso: evita que los cambios del prototipo se incorporen a una tirada de producci\u00f3n equivocada"},"content":{"rendered":"
\n

The difficult part of a second prototype is often knowing exactly what changed after the first one. A trace repair, a component substitution and a firmware workaround may all exist in different places. A simple release process helps turn those discoveries into an unambiguous next build.<\/p>\n

Give each build a clear identity<\/h2>\n

Choose a readable board revision and use it consistently in the design records and release-package name. Keep the hardware revision separate from the firmware version and assembly variant. One bare board can support several population options, so a board label alone may not describe everything fitted to it.<\/p>\n

Separate observations from approved changes<\/h2>\n

Keep a change list with the observed issue, proposed correction and the evidence used to accept it. \u201cConnector problem\u201d is hard to act on. \u201cConnector orientation conflicts with the enclosure opening\u201d gives the next reviewer something specific to check. Record unresolved questions as unresolved rather than hiding them in an apparently final archive.<\/p>\n

Release the file set together<\/h2>\n

Once changes are approved, generate the fabrication and assembly outputs from the intended revision. Keep a copy of the exact package sent for quotation or production. Avoid repeatedly replacing the contents of an archive called \u201cfinal.zip\u201d while keeping its name unchanged.<\/p>\n