> I think the main problem here is semver.

Maybe it’s ironic that semver (machine-readable versioning) ended up being a liability due to interpretation by people (i.e. we can’t release a 2.0 because it would “send the wrong message”).

While semver was intended as machine-readable versioning, and still mostly is, given that sevmer does not say what an "api" is in any way means that it's still defined by humans at the end of the day.

I think I'm in agreement :)

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/

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

And I agree with you on the solution: version the language (or whatever other more conceptual thing) by year and the program by semver. It’s the only thing that makes sense given the constraints.