Some examples, meant to illustrate some various ways semver is intentionally not followed, include:

kubernetes/kubernetes: The REST API is semantically versioned but the Go API is not. With each new minor release of Kubernetes the Go API has major changes. Existing codebases that import kubernetes/kubernetes (a common situation) have been pinning to minor version ranges

This comment has been minimized.

edited

I am also interested in this question as a consumer of non-semver compliant packages, which is causing my builds to break. In my case, I am dealing with the docker project.

If for business, political or some other non-technological reason, a project won't do semver, is there a recommendation for what I, as a consumer of that library, should do? Forking the project, adding a go.mod, and adding appropriate semver git tags would "fix" the problem of not being able to build my code but I am not sure it addresses the political question and of course that has a variety of unfortunate costs and side effects.

Alternatively, maybe the go community would quickly just refuse to consume libraries that don't use go modules. In which case, its a non-issue.