Re: PCB version control

On 3/25/2025 9:29 AM, bitrex wrote:

OK so...how should I do revisions of this PCB/product (the product is the PCB) again? It has a board, and uP code, and FPGA code. Can you provide a motivational example

If the product is a bare PCB, then it has a document (part number)
that describes how the board is made (take the Gerbers known of
as part number 12345 and ship them to a service bureau to shoot
the board on FR4 -- or whatever; apply the acceptance procedure
described in 17743; if passed, package as per the procedure outlined
in 88352.
If it is *more* than a bare board, then similar issues apply
at all depths in the assembly.
E.g., every source file needs a unique identifier (part number);
an object without an identifier doesn't exist!  And, can't be
reproduced, tracked, etc.
A document (another part number) exists to tell <someone> how to
make that source file into a more usable form (e.g., a .o, .so, etc.)
by identifying the tools (more part numbers) that are used to
perform that activity, any options (command line switches) and
operating environment (identifier) along with the step-by-step process.
Eventually, you have an "image" -- defined by a part number.
And, another procedure (part number) that tells you how to put
that image *into* that MCU.  And, how to put that part on the board,
etc.
Throughout, you've laid specific instructions that allow
someone unfamiliar with your product or process to recreate
your product in the absence of you, your staff and any
"folklore".  The more superfluous "mechanisms" you have
in place (like numbering systems that have to be maintained
and updated as your original needs prove to be inadequate),
the more costly it is to do this.
Most "regulated" industries are big on "process".  Imagine
you and your staff *dying* -- would anything be "lost"
that would interfere with recreating ANY version of your
product?
You need to be able to recreate old/obsolete versions as
you may have need to reexamine their implementations if
some "old, existing product" in the field starts exhibiting
problems that snuck through your testing.  Or, someone may
want/NEED to purchase a new instance of an OLD version
based on their own requirements or requirements of their
industry.
[A firm I worked for based a product on an Apple ][.  Over
time, it got hard to *find*/acquire Apple ]['s!  So, they
were faced with scouring eBay, etc. in order to have that
"component" to include in new instances of their old,
VALIDATED design!  Replacing the Apple ][ with something else
(equivalent?) would mean the entire product would have to be
revalidated (costly).]

Apparently HP had it right when every product was just like some meaningless number followed by a revision letter, eh?

Part numbers don't *include* revision indicators.
*Any* 123456 is equivalent (fit, form, function) to any
other 123456.  If "rev X" is *required* (e.g., to fix a
problem with an earlier revision), then you have to issue
a new part number -- that can be referenced in your top
level BoM, product number, etc.
This is the flaw in *software* versioning; the version
becomes part of the part number as version N of 123456
likely "fixes" a problem in version M of 123456 (where
123456 is a software assembly).
I.e., would you expect version M and N to behave identically
(indistinguishable F/F/F)?
You can make a revision to a "file" that doesn't alter its
fit, form or function (e.g., I can include commentary in
a file and the file still produces the same binary -- the
revision doesn't alter F/F/F.)
[This requires expert skill to ensure that the two versions
are, in fact, identical -- in all ways that matter.  E.g.,
if the time required for an algorithm to execute is a
significant criteria, then any change that alters it mandates
a new part number -- lest you use an earlier revision.
Ditto memory requirements, etc.   As a result, many industries
just insist on NO changes to an object -- rather than having
to determine if a particular change is "significant"]
If some change *fixes* a problem, then you wouldn't want
rev M to sneak out into the wild -- it is defective!
E.g., we replaced the bolts that hold the engine in the car
because the old ones were too weak.  we sure don't want to
let the line build any more cars with those old bolts
so we'll specify a different P/N.  (OTOH, if you wanted
to use BLUE bolts instead of RED ones -- and the visible
appearance didn't alter F/F/F -- then you could just issue
a new revision that specifies BLUE instead of RED; no one
going to lose an engine due to the color change!)
Note that you can have different part numbers/identifiers
that you expose to customers.  But, you have to create a
map that allows those to be converted to your "internal"
part numbers.  Much the same way that you take "customer
part numbers" from your suppliers and map them into
YOUR internal part numbers.