Standard commands like go build or go test will automatically add new dependencies as needed to satisfy imports (updating go.mod and downloading the new dependencies). But there are several different situations which will result in the different version selections:
-
If a repository has not opted in to modules but has been tagged with valid semver tags, meanwhile, it’s v0/v1 module, see this:
not opted in to modules: means no
go.mod
in source treevalid semver tags: means the repo use git tag to tagged as something like
vX.Y.Z
v0/v1 module: means the value of major version(that is X) is 0 or 1, e.g. v0.1.0, v1.2.3
Then, it will use a
pseudo-version
, something likegithub.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181
-
If a repository has not opted in to modules but has been tagged with valid semver tags, meanwhile, it’s a v2+ module, see this:
v2+ module: means the value of major version(that is X) is >=2,e g. v4.1.0
Then, it will show as
incompatible
, something likegithub.com/zeromq/goczmq v4.1.0+incompatible
-
If a repository has already opted in to module s, but not have been tagged with valid semver tags:
Then, it will behave as 1, use
pseudo-version
. -
If a repository has already opted in to modules, and has been tagged with valid semver tags, meanwhile, it’s a v0/v1 module:
Then, it will behave normally like
github.com/stretchr/testify v1.3.0
-
If a repository has already opted in to modules, and has been tagged with valid semver tags, meanwhile, it’s a v2+ module:
Then, when importing in the source code, we need add
/vN
at the end, e.g.,import "github.com/my/mod/v4"
, and ingo.mod
it will behave likegithub.com/my/mod/v4 v4.1.0
Source: