> 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 T

> 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).