Earlier quoted context omitted.
He sure makes no small attempt at marketing the term, and himself https://www.hyrumslaw.com/ In any case, my point is that it this observation has no relevance on the applicability of semantic versioning. One is a practical approach at making the best out of versioning. The other is a rather simple observation that given sufficient enough users of an API, all parts of the API will be depended on by someone. To go and…
> One is a practical approach at making the best out of versioning. I think the observation is that this is sort of going to inevitably fail, and people will get mad at you anyway (perhaps more mad than if you didn't have any semver promise to begin with). Right, like say you maintain a library and refactor something in a patch version bump. It affects something that isn't a documented aspect of your api, but is none…
> Per hyrums law, this would mean that essentially all changes should result in a major version bump, which defeats the purpose.
So, what is the point you want to bring across?
> I think the observation is that this is sort of going to inevitably fail, and people will get mad at you anyway (perhaps more mad than if you didn't have any semver promise to begin with).
Yes, and? It has absolutely zero impact on the applicability of semantic versioning, its purpose, and its utility. Nor do I find this observation particularly novel, or surprising. Are you suggesting to do away with semver, because a patch update given a theoretical "enough usage", will break for someone? We already have that granularity, just lock the version you use to the exact patch, and you're good. That way, you treat any change as a potential braking change, and the end result of this defeatist attitude is covered.
> The ultimate conclusion from this approach is that for a widely enough used api, you will always break someone, so you need to ship a migration story instead of a change, or you need a way to assert that your change won't break any of your users, which short of being able to run all of your dependencies tests isn't possible. This can be achieved in a corporate world, but not in the OSS world. And so yes, one of the fundamental truths of software engineering is that semver is fundamentally broken. It may be the best thing we've got, but it's absolutely not a magic pixie dust. You will still break your dependencies, and your dependencies will still break you, and you should prepare for that, semver or not.
And again, this is just beating the same dead horse. What's the actual point in relation to semantic versioning? Semantic versioning is not "fundamentally broken", that conclusion is ridiculous. Semantic versioning an engineering best practices. These things, and "logical thought experiments" rarely agree with each other. Suggesting this is therefore fundamentally broken, with not a single clue given as to how to improve it, is what I'm referring to as a defeatist attitude. A "best effort" must improved with a "better effort". So far, I've just seen "meeh, what's the point".
> Yes, and? It seems odd to drag someone for marketing themselves, on of all places, hacker news.
I'm not dragging them for marketing themselves. I'm annoyed about the triviality of the "observation" being referred to as a named law, in a contrived attempt at credence. It doesn't help to then see this used as attempting to make a point it has no grounds for. Not every xkcd observation needs to be coined by someone and called a "law".