Context

Prior to Go 1.21, the go directive in go.mod files was only a suggestion. Starting in Go 1.21, the compiler will refuse to use modules that declare a newer Go version:

The go directive sets the minimum version of Go required to use this module. Before Go 1.21, the directive was advisory only; now it is a mandatory requirement: Go toolchains refuse to use modules declaring newer Go versions.

As a result, it's possible that a module that compiles with Go 1.18 might not compile with Go 1.21 if any of the dependencies declare a Go version newer than 1.21. See an example failure here from this build.

Example

Consider the following example, which involves a module "b" that depends on library module "a".
– a/go.mod

module a

go 1.22

– a/foo/foo.go

package rand

import "math/rand/v2" // Added in Go 1.22

func Foo(n int) int {
	return rand.Intn(rand.Intn(n))
}

– a/bar/bar.go

package print

import "fmt"

func Bar(v []int) {
	for i := range v {
		fmt.Println(v[i])
	}
}

– b/go.mod

module b

go 1.22

require a v0.0.1

– b/main.go

package main

import "a/bar"

func main() {
	bar.Bar([]int{0, 1, 2})
}

Compiling module b with Go 1.18 would work because it only uses the "a/bar" package, which doesn't require anything from Go 1.22. However, compiling module b with Go 1.21 wouldn't work because Go 1.21 treats the go directive as a requirement, and the the module's go directive specifies that it requires Go 1.22. We should build with Go 1.21 in our CI to catch possible build failures due to dependent modules.

Definition of done

• Add a compilation check with Go 1.21 in CI.
• (Optional) Compile with every Go version from 1.18 to the current Go version.

Pitfalls