You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 to v0 packages or unversioned packages.
go get -u bumps the minor&patch release, which is only safe to do on v1+ packages based on the recommendations.
My proposal is to make go get -u default behaviour for v0 packages only to bump patch release. That way go 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 on golang.org/x packages. And of course go get -u logic becoming more complex.
might this break tools such as go-mod-upgrade and not least the vscode go that doesn't know about changes in the go get behavior? Also, from my own experience there are two sides to the v0 coin: as there never was any guidance from the go project on v0 minor handling, quite some deps I work with are bumping the minor on new features, not necessarily API breaks. This proposal would create more friction for users of these modules. The UX would get more complex by first breaking existing tools and then "fixing" it by adding more options, and thus complexity.
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 go list -u -m all to figure out what can be updated and then uses go get -d for every module to do a specific upgrade.
Also, from my own experience there are two sides to the v0 coin: as there never was any guidance from the go project on v0 minor handling...
If you add to the public API, make a breaking change to a v0 module, or upgrade the minor or version of one of your dependencies, increment the MINOR version for your next release. For example, the next release after v0.1.0 would be v0.2.0.
If you fix a bug in an existing version, increment the PATCH version. For example, the next release after v0.1.0 would be v0.1.1.
This proposal would create more friction for users of these modules.
I do agree with that, which is why I mentioned things like golang.org/x.