I want to require a certain version of a Go package that has not yet been converting to using modules, I want to require this in my go.mod file. Specifically, the package is "github.com/docker/docker/pkg/[email protected]"
When I run the following command, I get the following output:
$ go get -v github.com/docker/docker/pkg/[email protected]
go: found github.com/docker/docker/pkg/system in github.com/docker/docker v17.12.0-ce-rc1.0.20200916142827-bd33bbf0497b+incompatible
As you can see, the version v17.12.0-ce is downloaded, not v19.03.13. I did also notice the "+incompatible" suffix, but I am not sure that has anything to do with the issue. According to the docs
the go command adds an +incompatible suffix to versions with major version 2 or higher without a go.mod file. +incompatible indicates that a version is part of the same module as versions with lower major version numbers; consequently, the go command may automatically upgrade to higher +incompatible versions even though it may break the build.
so I understand that this package does not have a go.mod file, however the downloaded version (17.x) is greater than 2, so I don't think +incompatible is the issue.
my question is: When I specify version v19.03.13, why does Go install v17.12.0-ce?
This is the version I want to use
This is the one that is downloaded
The version listed in the
go.modpseudo-version does not matter for repositories that are not go modules. The versionv19.03.13is not a syntactically valid semantic version, so the go tool will walk up commit tree to find one, and the first valid semver it encounters happens to bev17.12.0(which is not intended to be a semantic version, but it is at least valid). The fact that the leading version isn't what is expected in the pseudo-version isn't a problem as long as go itself can reproduce and parse the result.If you look at the trailing commit hash, you have
bd33bbf0497b, which is the correct commit id for thev19.03.13tag.