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.