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
4. Downgrade golang.org/x/mod from v0.22.0 to v0.16.0

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

I tested various Go versions locally using code from PR #386, with the same Python .venv (pybindgen installed) on Apple Silicon (darwin/arm64):

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.

---

Should We Maintain Compatibility With Older Go Versions?

Arguments for

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

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

Arguments against

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.

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

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

4. Test matrix simplicity: Fewer supported versions means a simpler CI matrix and fewer version-specific skip conditions 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.

---

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!

[b-long]

For what it's worth, my thinking is that we (as a gopy community) can mark this discussion as "Accepted" on the 16th or 17th. That would mean the community had 1 month to comment on the proposal, and provide an opposing argument.

As it stands, it seems there is no reason to continue support for Go 1.21.x - I'll try to check-in again on the 16th or 17h.

[b-long]

Marking this as "proposal-accepted", and closing this issue as resolved 🙂

@kousu and @rcoreilly Separately, I wonder if we might establish a process for the minimum go version to be updated. I really like the table that @kousu provided, and I think it'd be good to have a regular / predictable cadence. That said, I think it'd be reasonable to make a new issue and/or pull request to implement that process.