Drop support for Go version 1.20?

[jamesx-improving]

As @rueian mentioned in a PR comment, it is recommended to "not to support Go 1.20". We also have to tailor things for 1.20 in the Makefile as well, including different dependeny versions, as well as workarounds on bugs.

Regarding Go's official Release Policy, Each major Go release is supported until there are two newer major releases. At this point (Feb 2025), 1.24 just released earlier this month, which means the one-year-old 1.22 just lose its support, not to mention the two-years-old 1.20.

On the adoption side, here's a quick search result count on various versions of Go in go.mod files on GitHub:

Version	Count
1.24	3.6k
1.23	113k
1.22	195k
1.21	139k
1.20	104k

Your input is highly appreciated!

[avifenesh]

If it brings security issues, I think we have to drop support.
Doing some checks, other libraries also don't support 1.20, as well as different maintained tooling.
The numbers are a bit “lying”, since the count should be on repos that have updated at least once in the last 1–2 years.
If it's a stale repo, it's not reflecting a real optionals users.
So, unless we have a way to really secure the usage, I'm in for dropping support.

[jamesx-improving]

the count should be on repos that have updated at least once in the last 1–2 years

That's exactly what I was thinking this morning when I wake up!

[jbrinkman]

I think it is relevant to look at what versions Valkey-Go supports:
https://github.com/valkey-io/valkey-go/blob/main/go.mod

Currently, it looks like they support 1.22

[avifenesh]

I checked all of the go clients, and maintained tools, not supporting 1.20

[jbrinkman]

I think this is worthy of a broader discussion on an overall policy for Valkey-Glide. With Node, Go and soon .Net versions having a regular version update schedule and clear Long Term Support policies, I think the project needs a similar policy so we don't have to keep having this discussion with every language version update. We could go with a strict policy that says we only support LTS versions, or we could go with a relaxed policy that says we support current LTS versions and one prior version. For example, in Go's case, this would mean we support 1.24, 1.23, and 1.22. For .Net this would mean we would support .Net 9.0 (current), .Net 8.0 (LTS) and .Net 6.0 (previous LTS). For Node this would mean we support Node 23 (current), 22 (LTS), and 20 (previous LTS).

I believe a relaxed policy allows us to keep the project current with the language vendors and their reluctance to fix security issues and bugs in older language versions, while also recognizing that many businesses are not quite as aggressive at keeping current with their software systems.

[avifenesh]

@jamesx-improving a decision made?

[jamesx-improving]

Although not reflected here in this discussion thread, but as part of the discussion on broader language version support policy drafted by @jbrinkman , I believe the majority agreed to at least drop support to 1.20, if not fully embracing the official Go Release Policy of supporting only the 2 latest major releases, which will put 1.22 out of support at this point.

[avifenesh]

So lets move it into an issue and make it a task

[avifenesh]

@jamesx-improving I moved it into an issue, and im closing the discussion.
#3442