Re: PCB version control

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.
 So, should they have sold the rev. 1.4 3B+ as something different
(3.1B+)?

No, they should have ENSURED the 1.4 version was compatible with
the 1.3 -- because they CHOSE not to expose the change to the user
by creating a different PART NUMBER.
(Remember, revisions are supposed to be interchangeable in terms
of F/F/F)

No idea what changed, but it must have been significant enough
to require a change to the bootloader.

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

I assume (hope) it was a
necessary change, i.e. it wasn't possible to make any more rev.
1.3 parts, and not just tinkering or cost reduction, though I
suspect the latter. In that case we'd happily pay (a little)
more for compatibility :(

Exactly.  At the very least, EXPOSE that change to me (by changing the
part number -- *name*, in this case).
We built a gizmo that relied on a third-party software component.
As it's "just a license" that we were buying (i.e., once you have
a copy of the code, all you really need is legal permission to
use yet another instance of it), we would defer paying for new
licenses ($5K) until we had to fill a new order.
Then, the vendor came out with a new release THAT WAS INCOMPATIBLE WITH
THE PRIOR REVISION.  (As I said upthread, a new VERSION/revision should
be interchangeable with the prior revision -- a CM issue that software
people don't seem to understand!)
And, the vendor refused to sell us a(nother) license for the earlier
version!  (i.e., we already HAVE a copy of the code -- just not legal
permission to use another instance!)
So, now we are faced with a "part that has gone obsolete".  And, have
to adapt our build to accept the "new" part.  All while the customer is
thinking that his item is "in the pipeline".
Thankfully, long lead times are the norm for these devices ($1M+ so
they aren't "kept in stock").  And, as each is somewhat custom, you
can make use of this up-front time to reimplement with the new
"component" while you're busy with the site inspection, P&ID and
other aspects of the sale.
Moral of story:  software, being ethereal, lulls you into thinking it
doesn't need to be "stocked".  So, you are far more vulnerable to it
"going obsolete" at a moments notice (or, at the whim of the owner).