Go version directives in go.mod files: some notes and crude usage numbers
Go modules use a
go.mod file to
specify various things. One of the directives that they can include
which sets 'the expected language version of the module', to quote
the specification's words. The specification goes on to say a bit
about what it's used for.
go' line in go.mod does not limit what versions of Go will
(try) to build the module (well, packages in the module), although
of course if the module uses something that's not in older versions
of Go, building will probably fail. This is important behavior,
because in current versions of Go, running '
go mod init' will
write the current version of Go into your new go.mod file as the
go 1.nn' version. This is reasonably behavior and probably won't
cause you problems, but you might want to watch out for it. The Go
version specified in the
go.mod can predate modules; in my
assortment of Go programs (and vendored packages), I have one that
go 1.9' and two that have '
I have a collection of various people's Go programs, their vendored
modules, and the dependent packages for the remaining non-modular
sitting around. In that collection, the distribution of Go versions
go.mod files is this:
31 go 1.13 23 go 1.14 20 go 1.12 15 go 1.15 15 go 1.11 2 go 1.10 1 go 1.9
(A real study should try to do some measure of the most frequently imported or used Go packages.)
I don't think '
go' directives are ever automatically updated by Go
module commands, so this represents some combination of what Go version
the modules were created with and what Go version people have explicitly
decided to call for (whether to insure backward compatibility or to set
a minimum version).
I expect that in the future we're going to see a burst of '
directives that specify Go 1.17 or whatever Go version modules become
mandatory in, as people are forced to turn long
ignored programs into modules. Some of that may be happening now in Go
1.16, since Go will now prod you about this if you haven't explicitly
$GO111MODULE to something.
PS: The development version of Go generally considers itself to be
one Go version in the future for this sort of thing, so right now if
you do a '
go mod init' with a development version it will create a
go.mod with '
go 1.17' in it. This is reasonable behavior, but might be