What exactly are you trying to accomplish that you cannot do at the moment?

Are you proposing this change as an alternative to the use of tags, or as an addition to them?

How would the go tool find a particular version? Right now it just lists the tags and branches. With your method, presumably it would need to look at every single change made to the go.mod file, which would likely be much more work.

Also note that a "git dump" isn't always necessary. With the presence of public module mirrors, you'll be able to download specific versions of Go modules without needing to use any VCS: https://blog.golang.org/modules2019

You can't rely on git tags or branches because go source files get routinely cut and pasted and moved and forked and whatever else people being people do, losing SCM metadata in the process (not to mention some git histories are huge and people deliberately trim them) so the only reliable way to track the version of a set of files is to read a module descriptor.

That's pretty much the same reason having the module name written explicitly in go.mod works, and relying on implicit info (directory hierarchy in GOPATH, URLs, git remotes) didn't work out.

go.mod finally made the module name explicit and reliable, but versionning is still not there.

Moreover when you need to manage piles of code, some in Go, others in something else, parsing a text descriptor is (relatively) easy, needing to run all the various language-specific tools to get versionning info is not.

This does not mean the go tool should forget about tag or branches, it should just write the result in go.mod so info does not get lost with scm metadata, and check go.mod info is consistent with what it sees in scm metadata when getting code (because if it is not consistent something is wrong, typically quick and dirty cut+paste+commit in the SCM).

To give another perspective. I am trying to integrate Go in systems that focus on full-cycle software management. As Russ Cox wrote himself in https://research.swtch.com/deps the current Go tooling posture is pretty much limited to an outward-facing “what do I need to download to build this code”.

In a full-cycle management system, you also need to answer questions like “what is this code”, “what is its version”, “how was this binary built, and from what code”. So robust naming and versioning info is not limited to third party code, it also needs to cover the codebase that calls this third party code.

not everyone gets its code through a git dump

That's true, but if you want to build in module mode you certainly do need a way to resolve versions to concrete modules.

We have a protocol for that, and that protocol communicates the versions in resource paths and .info files. See https://tip.golang.org/cmd/go/#hdr-Module_proxy_protocol.

you also need to answer questions like “what is this code”, “what is its version”, “how was this binary built, and from what code”.

See debug.BuildInfo and #29814.

As far as I can tell, the only problem reported here that is not covered by an existing issue is the error message from the parser.

And the HDR protocol is useless to trace the versioning intent of the code author since it relies on generated files, the info itself is not present in the source files written by the code author. Somewhere all the cleverness of go get transformed sharing a plain version number with your code users into a massive infrastructure job.

Also, from what I see in the spec right now HDR forgot about the initial intent to help people share go code through plain fileservers, you'll need specific tooling to generate info files and the list element is an index that needs regeneration every time a new module is dropped in the repository (but I won't comment more about HDR since looking at it closely is the next step)