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 Newsgroups: sci.electronics.design Subject: Re: PCB version control Date: Thu, 27 Mar 2025 08:40:40 -0700 Organization: A noiseless patient Spider Lines: 63 Message-ID: References: <67e1a08c$0$3831$882e4bbb@reader.netnews.com> <15l3uj5eed6mbtlnas1cemu2cn5iukog6b@4ax.com> <67e2588f$0$2785$882e4bbb@reader.netnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 27 Mar 2025 16:40:42 +0100 (CET) Injection-Info: dont-email.me; posting-host="acb7144c8c58caff5b2723e4608fc907"; logging-data="620993"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/+DJBQ1cZ37jUVhAkB2QNk" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:Uupnbd1zEocuqkm05NqhN3TTnjQ= Content-Language: en-US In-Reply-To: Bytes: 4508 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).