The problem with semver is the actual lack of tooling built around semver. Humans aren't robots, a bug fix might actually be a breaking change, without the author noticing it. What to do in that case. Yet semver is better than nothing, all other versioning schemes are not that useful.
I'd say that if you can't anticipate something being a breaking change or not, then you have an architecture problem. Likely violating principle of single responsibility.
Your software should define what the inputs are and what the outputs are. It should be clear when you're breaking an interface.
> tl;dr: There are next to no "backwards compatible API changes" in go. You should explicitely name your compatibility-guarantees.
It's not a problem in languages that come with a package manager, or at least promote a specific one to handle dependencies.
It's only a problem in languages where developers thinks "you don't need that". There is this weird belief in the Go community that Go is a miraculous language where good programming practices don't apply because Go magically make them irrelevant. It also stems from the Go team itself, which used to claim that "at Google, we don't need this or that" and then the Go community spreading the "gospel" : "Go doesn't suit you because it wasn't created for you"(?!?).
Hopefully Russ Cox sees that light, he even wrote a paper about "Go zealots" ( https://news.ycombinator.com/item?id=13356531 ) and how they refuse any change in the language, even when "teams at Google needs it". The irony
> It's not a problem in languages that come with a package manager, or at least promote a specific one to handle dependencies.
No. It is pretty much only a problem in languages with a package manager. Languages without the notion of package versioning don't run into the issue of needing to have a notion of what a version is, clearly. A package manager just helps automatically enforce versioning, it does zero to help you figure out what the correct version is.
Yes, not coming with versioning and a package manager comes with its own disadvantages and pain, no doubt. And we can surely debate which pain outweighs or is worse. But claiming that package managers would solve this problem just isn't true (I wrote the article when the whole "SemVer and package manager for go" debate was taking off and I tried to come up with a better approach).
> It's only a problem in languages where developers thinks "you don't need that". There is this weird belief in the Go community that Go is a miraculous language where good programming practices don't apply because Go magically make them irrelevant.
Can you source that? I am one of the most vocal opponents of package managers and versioning in go, but this contradicts everything I believe about it. My believes aren't, that go doesn't need it, but that a) it comes with its own set of problems, that b) those outweigh most of the benefits, IMO and c) that by considering and discussing it carefully, we might be able to come up with an actually innovative new solution to the problems.
Nowhere do I claim that go doesn't have those problems, on the contrary. I'm just arguing that, traditionally, go is a language that prefers doing things right over doing things like they were always done.
