Do they have an announced support policy for versions? If they have a policy that says they support the 3 most recent stable major versions, I wouldn't count d

Do they have an announced support policy for versions? If they have a policy that says they support the 3 most recent stable major versions, I wouldn't count deprecating support for a non-supported version of Go to be a breaking change. They aren't breaking anything because your version of Go is no longer supported on those versions. Whether you think that deprecating support for a language version (regardless of whether it continues to build with that version or not) requires a major version change is probably a matter of personal opinion. I would tend to say no, but I can see valid arguments for it (mainly because semver doesn't actually give us enough bits to communicate granular info). What would be ideal is if we had a means of communicating more information about releases of code and their relationship than semver provides. I.e. I can publish a repo and add some kind of "language-support.json" document that specifies I support the 3 latest major releases of Go, and have the package manager figure out whether my version of Go is supported. Other ideas for metadata would be the ability to add labels to releases, and have the option to filter/prioritize upgrades based on those. I would love if package managers supported labels as part of the metadata, and I could get a summary of all the labels between my current version and the new version. So on an upgrade, I could get a label diff for the package versions like "security:cve-1234 feature:oauth2-support bugfix:stale-kafka-messages". Those are cherry picked things that make nice labels, not everything makes sense in those messages. But sometimes it feels like we just do global updates and make sure everything builds, just to keep the tech debt low. I have no idea what actually changed in the package, and as long as it builds and tests pass I don't have to know. That's because we have so many dependencies, and it would take ages to read the release notes for all of the versions of all of the dependencies between our current version and the new one. Labels provide a means to communicate a succinct version of what changed; succinct enough for someone to read while they're waiting on tests to run.