throwaw180ay

10년 전discuss

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.

throwaw180ay

10년 전discuss

> 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

comments