@gopherbot, please add labels modules

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.

For projects like these, with existing processes and behaviors, what is the direction for them?

Fundamentally, modules require consistent, predictable tagging.

For cases like kubernetes/apimachinery, it may suffice to add v-prefixed tags alongside the existing other-prefixed tags.

For cases like kubernetes/kubernetes, the way we have chosen to communicate breaking changes in Go modules is to provide separate import paths. In general I would recommend maintaining compatibility with the last legacy API at the existing import path, and using semantic import paths — that is, a new import path for each incompatible version — from that point forward.

The latter cases may require more API stability than a project is used to, or may require moving to an explicitly-unstable tagging scheme (such as v0 or prerelease tags). (Of those options, API stability would arguably provide a much better user experience than unstable tagging.)

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?

It's really up to you to decide what libraries to use and how to deal with unstable APIs.

If you don't mind dealing with churn, you can always leave your own project in an unstable (v0) version range. On the other hand, if you want stability, then you will also need to choose stable dependencies.