3 ms·
Risk tells you nothing. We're trying to condense a changelog into a few small numbers. There's no sense from it. Upgrading software almost always requires chec
by junon 6y ago
Risk tells you nothing. We're trying to condense a changelog into a few small numbers. There's no sense from it.
Upgrading software almost always requires checking things. I've never seen the point of versioning schemes and instead find simple linear numbering way more reasonable. There is no simple way to compare two versions of software, generically, aside from a human reading them.
The same people who tout semver as being the end-all-be-all are also okay with lock files. It makes no sense to me.
- extrapickles 6y agoRisk 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...