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.

Sign up for GitHub

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

Jump to bottom

cmd/go: go Mod should use go dep SemVer behavior for < v1.0.0 #37117

Closed
EngHabu opened this issue Feb 7, 2020 · 5 comments
Closed

cmd/go: go Mod should use go dep SemVer behavior for < v1.0.0 #37117

EngHabu opened this issue Feb 7, 2020 · 5 comments
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge GoCommand cmd/go modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Backlog

Comments

@EngHabu
Copy link

EngHabu commented Feb 7, 2020

What version of Go are you using (go version)?

go version go1.13.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GO111MODULE="on"
GOARCH="amd64"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPRIVATE=""
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

I've a project with a dependency on lib A version v0.3.2, I ran:
go get -u ./...

lib A available versions are: v0.3.2 and v0.4.0

What did you expect to see?

Go.sum/go.mod should not update to v0.4.0 since it's a break change based on dep convention described here:
https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md

What did you see instead?

It pulled v0.4.0 instead which lead to compilation errors
@cagedmantis cagedmantis changed the title Go Mod should use go dep SemVer behavior for < v1.0.0 cmd/go: go Mod should use go dep SemVer behavior for < v1.0.0 Feb 7, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Feb 7, 2020
@cagedmantis cagedmantis added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. FeatureRequest Issues asking for a new feature that does not need a proposal. labels Feb 7, 2020
@cagedmantis
Copy link
Contributor

The go module behavior is documented at: https://github.com/golang/go/wiki/Modules
This would change the expected behavior for all current users of modules. I've marked it as a feature request.

@cagedmantis
Copy link
Contributor

/cc @bcmills @jayconrod

@bcmills
Copy link
Contributor

bcmills commented Feb 7, 2020

go get -u explicitly requests that versions be upgraded. If we were to avoid upgrading v0 dependencies with -u, those dependencies would never get upgraded and fixes to bugs would never be applied: according to the Semantic Versioning spec, at version 0 “[a]nything MAY change at any time”, including from v0.3.1 to v0.3.2, so literally no upgrade at all would be safe.

If you don't want to pull in breaking changes, either don't pass the -u flag or don't depend on modules that are still unstable.

@bcmills bcmills closed this as completed Feb 7, 2020
@EngHabu
Copy link
Author

EngHabu commented Feb 9, 2020 •
edited
Loading

So we essentially created a situation where:

  1. There is no safe migration path from dep,
  2. There is no safe upgrades for v0 libraries,
  3. There is no convergence path?

It seems that -reading that v0 is all fair game- makes it way less useful (specially to safely iterate). 

And I'm not sure what was so "bad" or "wrong" about Dep's approach that it was decided to diverge from? was it maybe considered to propose an update to SemVer to reflect that behavior....

I would like to use this issue to at least document the thought process that went into this decision...

@jayconrod
Copy link
Contributor

@EngHabu The thought process and design decisions that went into modules are well described in Russ's series of blog posts. In particular, see The Principles of Versioning in Go.

@golang golang locked and limited conversation to collaborators Feb 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge GoCommand cmd/go modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
6 participants
@EngHabu @cagedmantis @jayconrod @dmitshur @bcmills @gopherbot