ubruhin
commented
5 years ago 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.
dbrgn
ouabache
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?