Proposal: Establishing Go 1.22.x as the minimum supported version

[b-long]

Summary

This issue proposes formally dropping support for Go 1.21.x and stating that go 1.22.x
is the minimum required version — which is already the case based on the go.mod file on the master branch.

---

Current State of go.mod (on master)

module github.com/go-python/gopy

go 1.22.0

require (
	github.com/gonuts/commander v0.1.0
	github.com/gonuts/flag v0.1.0
	github.com/pkg/errors v0.9.1
	golang.org/x/tools v0.29.0
)

require (
	golang.org/x/mod v0.22.0 // indirect
	golang.org/x/sync v0.10.0 // indirect
)

The go directive in go.mod already declares go 1.22.0 as the minimum. This means Go 1.21.x
users are already technically excluded — Go's toolchain management (introduced in Go 1.21) will
attempt to auto-upgrade or refuse to build depending on the user's GOTOOLCHAIN setting.

---

What Would Be Required to Support Go 1.21.x

To re-enable Go 1.21.x support, the following changes to go.mod would be necessary:

1. Lower the go directive from go 1.22.0 to go 1.21
2. Downgrade golang.org/x/tools from v0.29.0 to v0.19.0 (the last version compatible with Go 1.21)
3. Remove golang.org/x/sync as a dependency (it gets dropped by go mod tidy under Go 1.21 constraints)
4. Downgrade golang.org/x/mod from v0.22.0 to v0.16.0

The resulting go.mod would look like:

module github.com/go-python/gopy

go 1.21

require (
    github.com/gonuts/commander v0.1.0
    github.com/gonuts/flag v0.1.0
    github.com/pkg/errors v0.9.1
    golang.org/x/tools v0.19.0
)

require golang.org/x/mod v0.16.0 // indirect

These are meaningful dependency regressions — particularly golang.org/x/tools, which provides
core functionality for gopy's code analysis and generation pipeline.

---

Test Results by Go Version

Today (2026 April 16), I tested various go versions locally, using the code found in this PR: #386

All tests were run locally using the same Python .venv (pybindgen installed) across Go versions on
Apple Silicon (darwin/arm64). Results as of this writing:

Go Version	Tests Run	Pass	Fail	Skip	Notes
1.21.x	36	35	0	1	Required temporary go.mod downgrade to run at all
1.22.x	36	35	0	1	Passes fully
1.23.x	36	34	0	2	TestBindCgoPackage skipped (issue #370)
1.25.x	36	35	0	1	Passes fully

The single consistent skip (TestPythonConfig in the bind package) is unrelated to Go version.

Note: Go 1.24 is also affected by the TestBindCgoPackage CGO issue (#370) and is skipped
for that test. Go 1.25 passes without any CGO-related skips.

---

Question: What Is the Benefit of Supporting Multiple Go Versions?

The question

Given that go.mod already requires Go 1.22.0, is there any meaningful benefit to maintaining backward compatibility with Go 1.21.x — or with older versions in general?

Arguments for supporting multiple Go versions

1. Wider user base: Some users or organizations pin Go versions for stability reasons (e.g., corporate environments, reproducible builds, embedded toolchains). Supporting older versions lowers the barrier to adoption.

2. Ecosystem consistency: Libraries and tools that support a range of Go versions are easier to integrate into projects that haven't yet migrated to the latest release.

3. CI coverage: Running tests against multiple versions can surface regressions introduced by changes in the Go runtime or standard library — catching bugs before they affect users on newer versions.

Arguments against (reasons to drop Go 1.21.x now)

1. Already effectively dropped: The go 1.22.0 directive in go.mod already prevents Go 1.21 users from building without workarounds (GOTOOLCHAIN=local, manual go.mod edits). The
   deprecation is a formality at this point.

2. Dependency cost: Maintaining Go 1.21 compatibility requires pinning golang.org/x/tools at v0.19.0 , a release which is already quite old. New features, bug fixes, and security patches ingolang.org/x/tools (used heavily by gopy for type analysis and code generation) would be unavailable.

3. Go's own support policy: The Go team officially supports only the two most recent major releases. As of this writing, that is Go 1.24 and Go 1.25. Go 1.21 is out of official support. See: https://go.dev/doc/devel/release#policy

4. Toolchain complexity: Go 1.21 introduced GOTOOLCHAIN management, making it possible for go.mod to declare a minimum version. Using this feature correctly is easiest when the declared minimum matches reality — i.e., we declare go 1.22.0 and mean it.

5. Test matrix simplicity: Fewer supported versions means a simpler CI matrix and fewer version-specific skip conditions to maintain in main_test.go.

Recommendation

Formally declare Go 1.22.0 as the minimum supported version. This matches the current go.mod, requires no code changes, and aligns with Go's own support policy. The CI matrix can then focus on Go 1.22, 1.23 (with the known CGO skip), and the two latest releases.

---

Related

• Issue "broken" since go 1.21 #370: TestBindCgoPackage fails on Go 1.23 and 1.24 due to a CGO issue
• PR fix TestBindSimple and TestBindCgoPackage #386
• The go 1.22.0 directive was already present on master before this issue was filed

[kousu]

I am in favour of this!

According to pkgs.org:

distro	end-of-life	go version
debian oldstable (12)	2 months from now	go 1.19
debian stable (13)	2 years, 4 months from now	go 1.24
ubuntu 22.04	1 year, 2 months from now	go 1.18
ubuntu 24.04	3 years from now	go 1.22
ubuntu 26.04	5 years from now	go 1.26
fedora 42	1 month from now	go 1.24
fedora 43	7 months from now	go 1.25

And I assume people on Windows and macOS get forced to upgrade more rapidly than Linux users. Windows users at least almost certainly get go directly from golang.org and/or are happy using go get go@1.22 if needed.

So this will only affect orgs on Ubuntu 22.04, and they only have a year left before being forced to upgrade. Meanwhile, gopy is broken for orgs and teams on the other end of the spectrum (#384, #378, #379 etc) and in that tradeoff I vote for those of us using up to date OSes.

[rcoreilly]

Sounds reasonable to me!