The impact varies by project and the consumers of that project, so this is really difficult to have absolute rules about and this is a good illustration of well

The impact varies by project and the consumers of that project, so this is really difficult to have absolute rules about and this is a good illustration of well-meaning people disagreeing about the impact of changes. I'm pretty sure a huge number of Go projects no longer work with earlier Go versions, it's just a question of how far back you go. If you're back at Go 1.10 I'd recommend freezing your dependencies and putting them in your own repo, it's the only way to be sure. Otherwise this is likely to happen to you again as people aren't great about supporting all versions of Go 1.x - it's quite a support burden. I would note that even the Go language itself has dropped architectures and support for bootstrapping with older Go versions without bumping the major version. I think that's fine. Of course that does break strict semver (oops), but nobody cares because nobody actually expects strict semver in real software. What's important is the impact - it's sometimes ok to remove features if nobody is using them and I've never seen a project use a major version for that. I've also never seen a project bump a major version for a breaking bug fix. https://golang.org/doc/go1.15#386 https://golang.org/doc/go1.15#386