Maybe I’m slow but why not? KiCad librarians have no qualms about periodically deleting, renaming and generally messing with symbol and footprint libraries, so that if you are actually using native libraries straight up, you end up with all kinds of mess on your hands. And here we expect a third party library to be backward compatible? I just don’t see the advantages. Old designs will use the symbols and footprints from the local cache. New designs shouldn’t use obsolete components to begin with.
1 Like
Hobbyist keep these parts around for a long time, go through their stuff sometimes and decide to use it up. Not a compelling reason but a reason.
For those outlier cases - chances are whoever bought a bunch of parts in a the first place would have those symbols and footprints in the local library. Even if they would have to create a new one from scratch (I’ve been doing it for years because most of the time I couldn’t trust KiCad libraries) it is not worth it to create bloated libraries and introduce confusion about which parts are still available. On the positive, alternative approach can be advantageous: that nagging reminder in EEschema that a local symbol couldn’t be matched to the symbol in the library can serve a reminder when re-assessing an old design to address components that are obsolete.
1 Like
Due to the varied nature of customers, I think it makes sense to keep the parts in the library for bit of time before complete removal. However, it should be made plainly clear that the part is not stocked and is not recommend for new designs.
I’d guess that most people would not mind having to download a few parts that have become recently obsolete. What I’d personally not like is to download a list of 100 parts where more then 50% of them are obsolete. At some point this becomes “bloat” and should be removed.
It looks like there is not 1 simple answer that will work for everyone. Some thought put into a mixed approach should keep the majority satisfied.
1 Like
I think we’re going to aim for appending _obosolete or _nrnd or _nonstock to any applicable parts according to its status on DK’s website. If I can figure out a low overhead way of keeping track of obsolete dates, we may roll off parts into an obsolete lib after a certain time frame so the parts can live somewhere and not be completely lost to the annals of history.
2 Likes
I would say this is somewhere that a new feature could be added to KiCad. Have a ‘status’ field to allow parts to be active, deprecated or obsolete that would then clearly indicate to the user when selecting them (possibly with a yellow or red background or something, plus a clear non-colour warning) that the part may not be readily available. Then it would be easy for Diki-Key or other library maintainers to just change the one part field as a part progresses through its life cycle.
Of course, the danger is that people will assume that in the absence of a warning, the part is OK so anything that doesn’t get updated is going to annoy those who rely on it as their only source of information.
This would work for digikey but not for the official lib. A part can be obsolete when you look at one distributor but it can still be sold by others. (This might even be depended on where on this world you live. Maybe a new regulation means this part can not be sold to you but can be sold to someone in china.)
And such a field does not need new features. You can add any field to your symbol you want. You can also use the description field for this. (Add a tag at the beginning of it for example)
A part is obsolete when the manufacturer declares it so, and all official distributors should be notified of that so in theory if KiCad was getting libraries from multiple distributors who maintained them in a timely manner, you’d expect them all to mark the same part obsolete pretty quickly. Then you’re just buying the remaining stock, and some distributors will sell out before others. You can also have ‘discontinued’, where the part is still being made but a particular distributor no longer stocks it, which is what I think you’re talking about.
The other side of this is sometimes what happens with NAND flash memory (as an example), where a part is obsolete but there’s a direct replacement, often when the manufacturer updates a process or on-board firmware and so technically has changed the part. This makes the old part number obsolete and a new one is assigned, which may only be one digit different from the previous part. For most people they won’t care about such minor things because it’s unlikely to make a difference, but for someone in volume production they’d want to get samples of the new part and test them before committing to a large production build even if they fully expect it to make no difference.
1 Like
Minor nitpick: in their schematic symbols, they seem to use size 60 for the text fields, instead of 50 as required by the KLC.