Re: PCB version control

On 3/24/2025 3:01 PM, Joe Gwinn wrote:

I’m with you—it’s good for stuff to be human-manageable.

 Below some size, this can be done.

For most non-trivial businesses, that size is quickly exceeded.
How many part numbers does Bourns assign to resistors?  JUST
resistors? Surely, unless you declare on Day 1 that you will
never use a particular power rating, physical size, value,
tolerance, etc., then YOUR numbering system must be able to uniquely
accommodate ALL of their parts!  (and, some way of accepting "identical"
parts made by some other manufacturer -- with undoubtedly different
part numbers!)
Repeat for chokes, BJTs, FETs, caps, etc.
And, when a new packaging (or fabrication) technology comes
along, you'll be ready to REVISE your numbering scheme to
accommodate *that*!
Will you ever know if a particular identifier maps to a *real*
device?  I.e., are there HOLES in your numbering system??

I've run into problems trying to code the sub-fields of small
addresses (used within some hardware gadget).  It took only two or
three implementations of such gadgets before one ran out of code
space.  The solution was to make each kind of gadget have its own
subfield coding, because these devices were bespoke anyway.

You end up with every type of device needing its own "system".
In which case, why not just adopt a system of using
    (manufacturer, manufacturer's-part-number)
instead of wasting your time trying to create another system that
MIMICs those on which you will rely?
If I depopulate the diagnostic/test connector from a board
"effective serial number XYZ", is that a new revision?  A new
board?  If I *repurpose* said connector at a higher level
in the assembly hierarchy, is THAT a different board?
If I install entirely different firmware (effectively changing
the high level function of the board), is THAT a new assembly?
If I replace the search algorithm in a piece of code with a
different algorithm, is this a new revision?  Or, part number?
What if I recompile the same sources for a different processor?
Or, different memory model?  Or, opt to redefine uint_t?
The more you encode in a part number, the more brittle your
numbering scheme becomes.  And, the more reliant you become on
fallible, REPLACEABLE human beings.
A few decades ago, I "no-bid" a job where a guy wanted to have a
DBMS track *properties* (i.e., land, building) for which he was
responsible.  He had a similarly crippled mindset:  the first
digit will indicate the part of town in which it is locate; the
second digit will indicate how many floors/stories; third digit
will indicate if it is a rental unit; fourth...
I.e., so that *he* could refresh his memory about a particular property
just by looking at some overly complex "identifier" ("Why not use
it's street address and save the hassle of creating a new system to
mimic this?  Put each property in a  nice, crisp manilla folder
with a photo on the front to act as a reminder -- because you're
designing a system that only *you* will find useful!")
[He likewise was a big fan of spreadsheets!  If he can't SEE all of
his data, then he fears some of it may have disappeared or been
corrupted!]
He found someone to take on the job (there are folks who will gladly
accept money for silly projects).  $200K and 18 months later, nothing
to show for it.  And, the guy found *himself* unemployed with his
responsibilities (and staff) absorbed into another department.
What can you tell about my vehicle from my license plate identifier?
Or, about a *person* from their SSN?  Phone number?  These are all
just identifiers and SOMETHING ELSE binds meaning to them!