Skip to content
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

Closed
mattfarina opened this issue Aug 8, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@mattfarina
Copy link

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

Notes:

  • 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?

@rajender

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2018

@gopherbot, please add labels modules

@gopherbot gopherbot added the modules label Aug 8, 2018

@jaloren

This comment has been minimized.

Copy link

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Jan 18, 2019

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.)

@bcmills bcmills added the Question label Jan 18, 2019

@bcmills bcmills modified the milestones: Unreleased, Unplanned Jan 18, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Jan 18, 2019

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.

@bcmills bcmills closed this Jan 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.