51–60 of 62 posts
Earlier quoted context omitted.
If it broke the exposed API, it should not be a minor. It doesn't matter if it's "by design" or not, people still rely on it and semver is how you communicate the breakage to them.
Per hyrums law, this would mean that essentially all changes should result in a major version bump, which defeats the purpose.
Earlier quoted context omitted.
> Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. Is that the main reason? I always assumed "I can't buy these machines for less than a year's salary" was the major difficulty onboarding.
> Is that the main reason? I think it is mostly the effect of them being legacy systems. Old systems become legacy systems if they are developed further. They can be difficult to work with but the mere fact that the language or platform breaks compatibility does not make that platform any better.
Earlier quoted context omitted.
Per hyrums law, this would mean that essentially all changes should result in a major version bump, which defeats the purpose.
It also makes "Hyrum's Law" pretty useless, doesn't it? Who names something like that after themselves? Well, I know at least one such case.
Not really. Hyrum's law is descriptive of reality and borne out of experience trying to update/change things. The point of it is to remind you that even when you think you aren't breaking things, you probably are breaking someone's workflow, and that your API surface is much larger than you think it is (performance, threading, ordering characteristics, etc. are all things that your dependencies will routinely rely on).
> Who names something like that after themselves? Well, I know at least one such case.
He didn't. Titus Winters probably deserves credit for the name. Hyrum deserves credit for the observation.
Earlier quoted context omitted.
> Unfortunately, end result of these policies is that nobody wants to develop for those systems anymore. Is that the main reason? I always assumed "I can't buy these machines for less than a year's salary" was the major difficulty onboarding.
That's an interesting question. In the late 90s, IBM had a competition in the same S/390 architecture, with Fujitsu and Hitachi mainframes. These could compete with IBM on price, so I don't think this would be a problem. It's hard to discern cause and effect here - maybe mainframes are expensive because IBM held to them and eventually became a monopoly. But I think the claims "mainframes are legacy and complicated" c…
I'm sure those were still really expensive though.
IIRC, IBM made a big investment to migrate to a 64-bit architecture, but none of its competitors in the mainframe space wanted to do the same.
Earlier quoted context omitted.
It also makes "Hyrum's Law" pretty useless, doesn't it? Who names something like that after themselves? Well, I know at least one such case.
> It also makes "Hyrum's Law" pretty useless, doesn't it? Not really. Hyrum's law is descriptive of reality and borne out of experience trying to update/change things. The point of it is to remind you that even when you think you aren't breaking things, you probably are breaking someone's workflow, and that your API surface is much larger than you think it is (performance, threading, ordering characteristics, etc. ar…
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 suggest that the logical extreme of a though experiment that, any change (bug fix or what have you) on an API, and given wide enough usage, will change/break something for someone, should somehow conclude in a defeatist mentality of "what's the point, everything becomes a major version", is... in my honest opinion, as uninteresting of an observation as they come. I'm sure it has more interesting applications elsewhere.
But then again, maybe I don't get what is supposed to be profound, or applicable, and I'm all ears.
Earlier quoted context omitted.
> It also makes "Hyrum's Law" pretty useless, doesn't it? Not really. Hyrum's law is descriptive of reality and borne out of experience trying to update/change things. The point of it is to remind you that even when you think you aren't breaking things, you probably are breaking someone's workflow, and that your API surface is much larger than you think it is (performance, threading, ordering characteristics, etc. ar…
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…
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 nonetheless something I depend on. I complain to you that you broke me with a patch upgrade. Well who is right? You did break me. Should I continue to trust you? Should I pin to a patch version (this makes semver useless)? Should you take more care to not break observable behaviors? How can you even know which behaviors are depended on, many will be unknown unknowns!
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.
> He sure makes no small attempt at marketing the term, and himself https://www.hyrumslaw.com/
Yes, and? It seems odd to drag someone for marketing themselves, on of all places, hacker news.
Earlier quoted context omitted.
I think GPs main point is not covered by semver at all - namely to not break anything out of the blue but have a transition period where API consumers can upgrade at their own leisure.
I do not know what GP is short for, apologies if I'm missing your point in my reply. One, if not the most important part of semver is communicating the nature of the changes, and in particular, how that change affects the use. I once used a library/tool that would detect vulnerabilities. The maintainers thought it would be a good idea to turn it in to a paid service, and a minor version upgrade caused it to fail sile…
Yes, SemVer communicates breaking changes, but only after they have happened. The point is that you should have a migration path ready long before the old API is no longer available.
The reality is that you have to be sensible and balanced. You can't keep BROKEN functions "because people rely on them", but you can't suddenly make a minor release (e.g.: from 2.3.4 to 2.3.5) completely changing the semantic of a feature you expose. You need to: - Avoid changing APIs just for the sake of change. - Announce breaking changes. - Document how users are intended to migrate from your old API to the new on…
Depends on what you mean with "BROKEN". Breaking changes actually break other people's code, tutorials, documentation, tooling and developer knowledge often for very questionable gains. There are many projects that are relied on by thousands, but they keep pushing breaking changes on a regular basis without providing tangible improvements. This is especially true for tooling, frameworks etc. for web development.
Earlier quoted context omitted.
I do not know what GP is short for, apologies if I'm missing your point in my reply. One, if not the most important part of semver is communicating the nature of the changes, and in particular, how that change affects the use. I once used a library/tool that would detect vulnerabilities. The maintainers thought it would be a good idea to turn it in to a paid service, and a minor version upgrade caused it to fail sile…
> One, if not the most important part of semver is communicating the nature of the changes, and in particular, how that change affects the use. Yes, SemVer communicates breaking changes, but only after they have happened. The point is that you should have a migration path ready long before the old API is no longer available.
The changes to an updated library don't affect you until you have upgraded to that version. The whole point of semantic versioning is to allow you or package managers you use to limit which libraries to update. So, semver is to let you know of braking changes exactly before they would happen, because until you actually upgrade the library, the change hasn't happened. Surely this makes sense? Maybe we are talking past each other.
I'd say nonsense. Backwards compatibility is better than any other option. From time to time you need to provide new, clean versions of old APIs and that's it. Things get deprecated (as in "best not to use this unless you are aware of the consequences". Aggregate over time, don't replace. Garbage collect when not reachable. This works for APIs as weel as for functional programming data structures. Clojure(script) app…
Suppose you create an API that allows users to enter nonsensical data or do things that are very bad for performance. Later, you realize your mistake, create a new, improved version of your API, and deprecate the old API. However, as long as you keep the old API for backward compatibility, you will have to deal with nonsensical data and poor performance.