2 ms·
Of course there's always Hyrum's Law[1], which can be summed up as > All observable behaviors of your system will be depended on by somebody. Even minor bugfi
by stouset 5y ago
Of course there's always Hyrum's Law[1], which can be summed up as
> All observable behaviors of your system will be depended on by somebody.
Even minor bugfixes will at some point invariably break somebody who depended upon the broken behavior. So semver really boils down to a human assessment of whether any potential breakage is incidental or intended.
[1]: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
- tialaramex 5y agoHyrum's Law reminds me of Frank Borman's "A superior pilot uses his superior judgement to avoid situations which require the use of his superior skill". On the user side Hyrum's law is a situation where you're going to need superior skill to fix it. You should instead have used superior judgement to avoid this situation altogether. As a library author I don't feel there's any value in considering Hyrum's Law. I can't help those poor fools, for all I know they're relying on me not updating the documentation to warn them they shouldn't rely on undocumented behaviour I'm about to change... Rust provides a pretty clear line in the sand on API changes we can use to choose semver policy. If your program has a proc macro to copy-paste sections of my source code into yours so you can access my non-public functions, I can't see that from where I am and you're lucky it ever worked, I am under no obligation to ensure it magically stays working in my next bugfix release.