Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: PCB version control
Date: Sat, 29 Mar 2025 13:33:30 -0700
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <vs9les$27ogn$2@dont-email.me>
References: <67e1a08c$0$3831$882e4bbb@reader.netnews.com>
 <vrsia0$1mccv$1@dont-email.me> <lmj3ujpg8eqannemaq74f8s9vqh2a5iooc@4ax.com>
 <vrsjna$1q7cg$1@dont-email.me> <15l3uj5eed6mbtlnas1cemu2cn5iukog6b@4ax.com>
 <vrsngv$1s889$1@dont-email.me> <vrsvfm$23j3t$1@dont-email.me>
 <67e2588f$0$2785$882e4bbb@reader.netnews.com> <vru1ed$341a4$1@dont-email.me>
 <vru201$341a4$2@dont-email.me> <vs06po$14pc8$1@dont-email.me>
 <r5i8ujlm93g029f0llvus2jnr692iva2n7@4ax.com>
 <cfk8ujtoq7sdl630mt9i93bf4ckgqqhvqj@4ax.com> <vs1lq2$2ekcr$1@dont-email.me>
 <slrnvua23o.41d.${send-direct-email-to-news1021-at-jusme-dot-com-if@vm46.home.jusme.com>
 <vs3rhq$iue1$3@dont-email.me>
 <slrnvug5hq.41d.${send-direct-email-to-news1021-at-jusme-dot-com-if@vm46.home.jusme.com>
 <vs9b26$1smn4$1@dont-email.me>
 <slrnvugdmh.41d.${send-direct-email-to-news1021-at-jusme-dot-com-if@vm46.home.jusme.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 29 Mar 2025 21:33:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cf42e35c928c809c40325679ab047905";
	logging-data="2351639"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191Y8Suhx/CSR0NsU33zAII"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:M8Xi/ExqEtKDqi5MRBvz3BncK2g=
In-Reply-To: <slrnvugdmh.41d.${send-direct-email-to-news1021-at-jusme-dot-com-if@vm46.home.jusme.com>
Content-Language: en-US
Bytes: 5159

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"?