As described in some detail in #50825, Go version compatibility has long been a pain point for gopls. At the time that issue was written, we hadn't deprecated support for building gopls at any Go versions. Since then, we've successfully dropped support for Go 1.12-1.17, and very soon will drop support for 1.18. These deprecations have for the most part gone smoothly, and we haven't heard about users getting stranded as a result.

Nevertheless, gopls's nominal support for building with the past 4 Go versions continues to cause friction, as outlined in #50825. With Go 1.21's forward compatibility, we look forward to the day when gopls' minimum supported Go version is 1.21, so that we can rely on forward compatibility to build gopls with the latest Go toolchain.

Per the support window of 4 trailing Go versions, that day would occur upon the release of Go 1.24. This issue proposes to move that day up one release cycle, to the release of Go 1.23 this August.

The rationale is as follows:

• The original support window of 4 trailing Go versions was related to the limited availability of recent Go versions in various operating system distributions and cloud providers. Since then the situation has improved significantly, and most release pipelines stay pretty up to date.
• Better support for language versions in the Go toolchain (go list, go/types, etc.) has made it easier to use the latest version of Go in your development environment while targeting deployment with older Go versions.
• Upon the release of Go 1.22, our survey results from VS Code indicated that 91% of our users were on Go 1.20, Go 1.21, or Go 1.22. Translating this to the release of Go 1.23, this suggests that 91% of users would be on Go 1.21 or later. That's a very large majority.
• VS Code support for managing Go and gopls installations has improved significantly (and we can do more before 1.23 if necessary).
• We have plans for standard library contributions in 1.23 that we want all gopls users to benefit from.

This last point is crucial: one of our major goals for 2024 is improved refactoring, and a foundation of that will be improvements to the AST, parser, and type checker (for example fixing #20744). Additionally, with type parameters on aliases (#46477) likely to land in Go 1.23, we are doing a lot of work (in #64581) to handle the new representation of Aliases added to go/types in Go 1.22. It would be a lot of additional effort (and arguably infeasible) to land these improvements with Go 1.23 while simultaneously continuing to support gopls built with older Go versions.

So, in summary, I think requiring Go 1.21+ to build gopls (via downloading the 1.23 toolchain) will save us a lot of resources and allow us to deliver a more reliable and robust product, and there seems to be little downside to dropping support for Go 1.20 at the time 1.23 is released.

EDIT: here are the actions to close this bug, assuming there are no objections:

• update the version support documentation at https://github.com/golang/tools/blob/master/gopls/README.md
• update the version compatibility table in VS Code; gopls@v0.16.0gopls@v0.17.0 will be the last gopls version to support both Go 1.19 and Go 1.20.
• start warning users who build gopls@v0.17.0 with Go 1.19 or Go 1.20
• Once go1.23rc1 is released, update gopls/go.mod with go 1.23rc1, and officially drop compatibility for older Go versions.
• make a decision about what to do for CI coverage. It seems OK to leave one legacy LUCI builders, since they will exercise Go command integration with older Go versions

CC @golang/tools-team