New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: Converting projects to semver? #26870

mattfarina opened this Issue Aug 8, 2018 · 2 comments


None yet
4 participants

mattfarina commented Aug 8, 2018

According to the docs modules must be semantically versioned. There is a problem in that many existing codebases and packages do not use proper semantic versioning as of today.

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
  • kubernetes/apimachinery: The tags used are prefixed with kubernetes- instead of v


  • This issue is to deal with intentional behaviors and existing processes and not accidental cases where semver is broken.
  • I'm using Kubernetes as an example because I am directly involved in that project and will be passing details on to others working that project.

For projects like these, with existing processes and behaviors, what is the direction for them? How can that direction be communicated in mass or automated with guidance?


This comment has been minimized.


rajender commented Aug 8, 2018

@gopherbot, please add labels modules

@gopherbot gopherbot added the modules label Aug 8, 2018


This comment has been minimized.

jaloren commented Aug 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment