4 ms·

I have been toying with the idea that version numbers should really be release.risk, where release is an incrementing number and risk is the projects estimate o

I have been toying with the idea that version numbers should really be release.risk, where release is an incrementing number and risk is the projects estimate of the risk of breakage from the previous release. Eventually the risk part of a release would not be static, so as time goes on it can be changed to better suite how risky that release was. This would then allow people to normalize risk (after enough releases) so they can have their own risk preferences. Also since we would be no longer trying to indirectly measure and indicate risk, we as an industry can get better at managing it as we would be getting higher quality feedback on how well we estimated or accepted risk. Tooling could be developed that examines your codebase and the dependencies deltas to better estimate the risk to you of taking the update.

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

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