3 ms·
Risk is an indicator for how you should allocate your limited time. Since most software projects these days directly depend on dozens of software packages, you
by extrapickles 6y ago
Risk is an indicator for how you should allocate your limited time. Since most software projects these days directly depend on dozens of software packages, you can't really afford to carefully vet each and every change to all of your third party dependencies (this is for the typical non-critical CRUD app, other applications it may vary).
Almost nobody has time to vet every line of code that changed or if the dependency is a binary blob, its expensive (and likely prohibited by licensing) to tell. That is why I would like a risk score over reading the tea leaves of a projects/products loose adherence to semver.
- junon 6y ago> you can't really afford to carefully vet each and every change It's not about vetting. It's about documentation. Putting a list of breaking changes on the Releases page, if any, and who each affects (e.g. "users of the .getFirstName() method will need to call .getName() now") is much more valuable than "2.4". You're trying to fit the former into the latter, which you... just can't. Information theory forbids it. I don't understand why we always jump to this dichotomy of "either you have a simple version scheme or you have to vet each and every single diff in every dependency and sub-dependency". No you don't - just read the release docs...