4 ms·

> However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue ma

> However, when pinning, when one of your static dependencies is broken due to a change outside your control (e.g. hardware, operating system, security issue making it unusable, or something else), the user's only recourse is to call the developer to fix the software. In practice, this happens so infrequently it can be ignored as a risk. (When it does happen, users generally don't expect the software to continue to work.) > dynamic linking has at least one extra advantage... You don't seem to be acknowledging the downside risk to dynamic linking which motivates the discussion in the first place. An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice.

AshamedCaptain 6y ago
> In practice, this happens so infrequently it can be ignored as a risk. Well I disagree there. Security issues or external protocol changes (e.g. TLSv1.2 to TLSv1.3) are rather frequent, not to mention usually customer wants to upgrade their machines (old ones broke) and existing operating system no longer supports the new hardware. > An update to a dynamically linked dependency which breaks my delivered artifact is an extremely common event in practice. Again, I agree. A "surreptitious" dependency update breaking the software is much more common. However, I have already acknowledged that _two times already_, and the point that I'm making is that it doesn't matter if you are pinning dependencies or not: customer CAN FIX these issues without help from the developer. They just have to roll back the update! On the other hand customer CAN'T fix the first issue (e.g. new hardware).