The code must naturally lead the upgrade process; and this is why we separate code from data; at least, this is a practical reason for doing so.
We are looking at one-man projects, here. One person to do the testing, update the code, and update the data.
And maintain sufficient spare motivation to perform library upgrades.
Dynamic linking introduces the problem of api compatibility. Any significant changes in the library routines may mean that the application using the library needs rigorous testing when the library is upgraded. Libraries are supposed to reduce your workload, but now you are at the mercy of the library author. Thus we need an api version; and we find that the library author may have bitten off more than they can chew.
In software there is no harm in reinventing the wheel, so long as you are responsible. Otherwise it is best to find libraries which are authored by those who let sleeping dogs lie.
I would not mention this, as seeming to be obvious, but that in recent times whole languages have been made obsolete.
As well the following seems obvious, but that software quality control is now a separate discipline:
Software improvements--features and bugs--are all quality improvements. Pay attention to the upgrade process and quality will take care of itself.