From @dbrgn on Sat Dec 08 2018 18:54:21 GMT+0000 (UTC)
Sooner or later, we will run into the situation where we used a generic footprint for a specific device, but then later notice that the footprint is not ideal and that we need a vendor-specific footprint.
Right now replacing the package is not supported in a reverse-compatible way, I think. Are there any ideas / plans on how to achieve that? Deprecating the entire device and replacing it with an almost identical new device doesn’t sound ideal to me.
Maybe we could deprecate footprint variants and simply add the new package as a footprint variant?
From @ubruhin on Sun Dec 09 2018 12:59:54 GMT+0000 (UTC)
The problem is that this is not trivial to fix. The project library updater is currently extremely simple and it works pretty fine as long as there are no breaking changes in library elements (like changing the package of a device).
But as soon as there is a breaking change, the updater completely fails (no element can be updated at all). To fix that, the updater would need to be designed much more sophisticated because it would also need to modify boards to update all pad UUIDs of traces connected to them. To achieve this, the updater would need to analyze the difference between the old device and the new one to know which pads were replaced by which.
If we ever make the updater that sophisticated (if even possible), we can remove the requirement that devices must not switch to another package. But until then we must just replace outdated devices with new ones, otherwise we would frustrate users because the project library updater breaks all the time.
Btw, for devices it’s actually fine to remove them instead of just deprecate them because there is no other library element which depends on devices (it’s the “top level” library element). So for the moment we could avoid too many deprecated devices by just removing them
But the general rule is always: Choose the proper package right after creating a new device. Think twice about if a generic package is fine or not.
Our standard library currently specifies a “R-0805” package. It has no defined height. If someone created a library with 0805 chip resistors, using that package would be “the right thing to depend on”.
Now I’m generating new packages for the standard library. The 0805 package is available in 3 different heights (0.6 / 0.65 / 0.7). I’m re-using the UUIDs of the existing so that packages can automatically be upgraded. When choosing which package to map to, I’ll of course use the highest package (0.7mm, to stay on the safe side).
If the author of that library notices that the package has been updated with a more specific version, but that the 0.6mm version would be more suitable for his/her device, then currently the device would need to be deleted and re-created with a new package.
Would be great if we could solve this with the library updater in the future™
What happens if the user wants to mix resistors with different heights? Updating the library gives you all or nothing. I want to specify which instances get each different height. If I specify a height of .65 then I want the
production engineer to know that they can substitute a .60 but not a .70 and it will still work.
You can mix heights as you want, since there are different packages for different max heights. The comment above was just referring to a library update we’re currently doing, where we replace the old chip resistors (without height) with newer packages that are available in different heights https://github.com/LibrePCB-Libraries/LibrePCB_Base.lplib/pull/15
