-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
proposal: cmd/go: go get -u
shouldn't bump minor release in v0
packages.
#64864
Comments
might this break tools such as |
Doing a quick skim of go-mod-upgrade code, it doesn't look like such a change would break it; but I didn't do a deep analysis. It does a
@thediveo https://go.dev/blog/publishing-go-modules#v0-the-initial-unstable-version seems to be explicit guidance on minor version handling. Although, it is a blog-post and not in https://go.dev/doc/modules/version-numbers#in-development or https://go.dev/ref/mod#versions
I do agree with that, which is why I mentioned things like |
Correct, it does mention both new API features as well as breaking changes for bumping minor. So we actually have both cases with all the ramifications. At least, this should be somehow synchronized with downstream; I would suspect the vscode go plugin, gopls(?), Gland(?), and maybe some of the CLI tools. |
I was thinking and there are alternate approaches such as:
I don't have a good design on neither of these, but jotting down some ideas, maybe somebody has better ones. Of course, not bumping unstable packages would be problematic in many scenarios, so this seems infeasible. Making it possible to differentiate between breaking and non-breaking, would be possible in a few ways.
Of course, none of these are a pretty solution. In the ideal world people would build a stable version from the start, but for any complicated API it can be difficult to get things right in a few years; especially if it's not your primary job. |
Would this affect go get pkg too? |
Proposal Details
I've seen people break their project with a
go get -u
in various forums. It does seem that the main culprits for leaving projects in a broken state are either due tov0
packages or unversioned packages.Currently https://go.dev/blog/publishing-go-modules#v0-the-initial-unstable-version recommends making breaking changes on
v0
via bumping the minor release; and non-breaking changes via bumping patch release. Forv1
and above, the breaking changes are indicated via bumping major release.go get -u
bumps the minor&patch release, which is only safe to do onv1+
packages based on the recommendations.My proposal is to make
go get -u
default behaviour forv0
packages only to bumppatch
release. That waygo get -u
would become less problematic.If the old behaviour is still desirable, something like
go get -u=minor
can be used.At the moment I'm unable to think of any significant downsides with this approach; other than
go get -u
not bumping minor releases ongolang.org/x
packages. And of coursego get -u
logic becoming more complex.Related issues:
The text was updated successfully, but these errors were encountered: