Re: PCB version control

On 3/29/2025 11:07 AM, Ian wrote:

On 2025-03-29, Don Y <blockedofcourse@foo.invalid> wrote:

On 3/29/2025 8:48 AM, Ian wrote:

On 2025-03-27, Don Y <blockedofcourse@foo.invalid> wrote:
>

On 3/27/2025 1:12 AM, Ian wrote:

A real example, that caused some pain, was the Raspberry Pi 3B+,
which at some point changed internally from rev. 1.3 to rev 1.4.
Unfortunately this was not made visible on purchase ("It's an RPi
3B+"), and the firmware image we were using wouldn't boot on the
rev. 1.4 hardware.

>
It's hard to imagine something changed that much that the
firmware couldn't have "massaged" the interface to be
compatible.

>
Well the newer firmware could handle both revs of course, but our
image was built on the older firmware which knew nothing of this
newfangled 1.4 tin.
>
And the new firmware only came with a new kernel, and new userland
software stack that was incompatible with our driver and application,
so we had to knife'n'fork the new firmware into the image as the
least worst solution.

>
And, you have to consider how your device "looks" (in terms of
compatibility) to *your* customers.  If you are trying to
keep compatibility between YOUR revisions (and avoid a part
number change), then you are forced to take extra measures to
accommodate their unexpected/unwanted "change".

 Quite. Fortunately our customer is somewhat less fussy then the US
DoD in that respect, though they do rather expect the thing to
actually work.

It's not just DoD that is "picky" about FFF.  Would you wear an
implanted pacemaker if the model you were given differed from
the one that was "validated" (certified)?  What sorts of
deviations from that model would be tolerable to your health and
well-being?

And, whats even more annoying, was that we'd done a bulk order for
the Pi3B+ to avoid this sort of thing, but half the delivery was
delayed by 12 months over the pandemic parts shortage.

>
If they had treated the "revision" as it should have been (i.e.,
identical FFF), then you wouldn't have cared if half of your
purchase was rev 1.3 and the other half 1.4 (or 1.9!).  Because
they would be INTERCHANGEABLE.
>
*Or*, you would have been made aware of the difference when
notified  "We no longer have any P/N xyz; would you accept
P/N abc, instead, for the balance of your order?"

 Our main objective was to avoid rewriting our application to use
a different kernel API at that point in time.

Yes.  The "wouldn't sell us a license" example that I cited was
similar.  If the vendor makes a significant change to a product
on which we rely, how much effort will it be for us to "hide"
those differences from OUR customers?
CM is considerably harder for software products because there
are so many aspects to FFF that can be affected; which are the
"significant" ones?  What does your *customer* consider to be
significant -- even if it is an aspect that you hadn't
considered worth "controlling"?