Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!border-2.nntp.ord.giganews.com!border-4.nntp.ord.giganews.com!nntp.giganews.com!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 26 Mar 2025 19:22:27 +0000
From: Joe Gwinn <joegwinn@comcast.net>
Newsgroups: sci.electronics.design
Subject: Re: PCB version control
Date: Wed, 26 Mar 2025 15:22:28 -0400
Message-ID: <cfk8ujtoq7sdl630mt9i93bf4ckgqqhvqj@4ax.com>
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>
User-Agent: ForteAgent/8.00.32.1272
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 88
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MvBgG2ubcRbR/Q+8XjZiA2z1gTFXUZmwL2yO/zKT5dycsmFKeUxUoc9xcxg2lyWwxXT55vSOG/5lQE2!K/LCHWDlsSbcEFillOUc2iPjUMJbnP7wdgmomwhnLDAYzzj86qkj/BwdmWCgkb8t0w==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40

On Wed, 26 Mar 2025 11:49:15 -0700, john larkin <jl@glen--canyon.com>
wrote:

>On Tue, 25 Mar 2025 23:28:01 -0700, Don Y
><blockedofcourse@foo.invalid> wrote:
>
>>On 3/25/2025 3:53 AM, Don Y wrote:
>>> On 3/25/2025 3:44 AM, Don Y wrote:
>>>>    "No.  I can replace a single page if necessary.  So, each EPROM
>>>>    /in the set/ can be at a different revision level.  It's up to
>>>>    Engineering to manage this (configuration management) so only
>>>>    valid "combinations" of those devices are incorporated into a
>>>>    released product."
>>> 
>>> This last is important.  If you want to force a production change,
>>> you have to change a part number, not a revision level.
>>> 
>>> E.g., I can revise an algorithm in a particular piece of code.
>>> Any revision will perform identically (if performance is
>>> defined by getting the correct "result"/return value).  A new
>>> revision may change some other aspect -- a faster algorithm,
>>> smaller, better documented, etc. -- but is same fit/form/function
>>> as the earlier revision.
>>> 
>>> If I *need* the product to use a newer version of that algorithm,
>>> then I have to give the function a new part number and update the
>>> BoM (makefile) to reflect that new part number.
>>
>>To drive this home:
>><https://www.product-lifecycle-management.com/plm-best-practice-revision.htm>
>><https://cdn2.hubspot.net/hubfs/2568500/Content%20Offer%20PDFs/MCL_Revision_vs_New_Part_Number_Infographic.pdf>
>
>Once a customer orders a Q451, they will expect to be able to order
>more Q451's. And we advertise the virtues of Q151's. So even if we add
>an LED or a software feature, we want to still call it a Q151, and
>roll the rev letter internally.
>
>The FFF thing is more a military requirement. Or a requirement from
>people like Intel with a copy-exact philisophy.

Form, Fit, and Function is now widely applied:

..<https://en.wikipedia.org/wiki/Form,_fit_and_function>

Joe




>
>><https://plmadvisors.com/plm-and-configuration-management-best-practices-part-numbers/>
>>
>>Assuming you have assigned part numbers to each software module/file,
>>consider how you currently think of "version control".  Is a rev B
>>version of that file INTERCHANGEABLE with a rev A version (see above
>>criteria)?  Likely the new file would have an augmented set of
>>test cases to reflect the fact that it is now tested against the
>>condition(s) that the earlier version was found to be defective!
>>
>>[So, *two* documents need to change before this is propagated]
>>
>>Chances are, it is not!  Rev B likely came about to FIX something
>>that was broken in rev A.  So, using rev B in place of rev A would
>>lead to a different product (one that is more correct than the
>>predecessor).
>>
>>As such, the part number for that file should change to reflect this
>>incompatibility.  This change would then propagate upward through the
>>assemblies to eventually reflect the fact that the finished product
>>with the "revised file" is, in fact, a different and not interchangeable
>>product with those that were built on the unrevised file.
>
>Compatibility of hardware and software is controlled by the BOM for
>this specific product/rev/dash number. The BOM has comments when that
>would help.
>
>We don't revise released software. That would be a nightmare.
>
>>
>>You surely wouldn't build a copy of last year's code base and try to
>>pawn it off as identical with the most recent codebase!
>
>Last years code was compiled and released and archived, with a drawing
>number and a rev letter. Any changes would be a new rev letter with a
>new release package. Why treat software any different than hardware?
>
>On the internet, people can and do push out buggy code releases often.
>On an electronic instrument, it's not a good idea to do that.