What is a pseudo-version, and when does the go command generate one?
Question 413MediumGo 1.22 to 1.25
A pseudo-version stands for an untagged commit. It has the form vX.Y.Z-yyyymmddhhmmss-abcdefabcdef, made of a base version, the UTC commit time, and a 12-character commit hash prefix. The go command generates one when you ask for a branch or a commit:
go get github.com/acme/lib@main
go get github.com/acme/lib@4f2a1c9
# go.mod: github.com/acme/lib v1.4.1-0.20240912083011-4f2a1c9e7b3d
There are three forms:
v0.0.0-...: no earlier tag exists.vX.Y.(Z+1)-0.2024...: the commit comes after release tag vX.Y.Z.vX.Y.Z-pre.0.2024...: the commit comes after a pre-release tag.
Pseudo-versions sort below the next real release, so MVS upgrades to v1.4.1 once it is tagged.
Gotchas: never write one by hand. The go command validates that the timestamp and base tag match the commit. Depending on pseudo-versions in a published library forces them on your users. Interviewers like to hear "pin to a tag before release".
More on Modules, Packages & Tooling
- Q411When would you use a replace directive, and why doesn't a dependency's replace affect your build?
- Q412Explain exclude and retract. Who writes each one, and how do they affect version selection?
- Q414What problem do Go workspaces (go.work) solve? How do they differ from replace?
- Q415How does vendoring work in module mode, and when is it still worth using?
- Q416How do internal packages work? Give an example of an allowed and a forbidden import.
- Q417Your CI can't fetch a private module from github.com/acme/secret. Walk through GOPROXY, GOPRIVATE, GONOPROXY, GONOSUMDB and GOINSECURE.