x/tools/gopls: once Go 1.23 is released, require Go 1.21+ (forward compatibility) to build gopls

[findleyr]

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.0 will be the last gopls version to support both Go 1.19 and Go 1.20.
• start warning users who build gopls@v0.16.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

[pjweinb]

Telemetry since Jan 1 gives the same results. The percentages for Go versions seen using gopls: devel 5 go1.19 3 go1.20 13 go1.21 71 go1.22 8

…

On Fri, Feb 23, 2024 at 7:06 PM findleyr ***@***.***> wrote: As described in some detail in #50825 <#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 <https://github.com/golang/go/milestone/326> 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 <https://github.com/golang/tools/tree/master/gopls#support-policy> for building with the past 4 Go versions continues to cause friction, as outlined in #50825 <#50825>. With Go 1.21's forward compatibility <https://go.dev/blog/toolchain>, 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 <https://pkg.go.dev/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 out 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 <#20744>). Additionally, with type parameters on aliases (#46477 <#46477>) likely to land in Go 1.23, we are doing a *lot* of work (in #64581 <#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. CC @golang/tools-team <https://github.com/orgs/golang/teams/tools-team> — Reply to this email directly, view it on GitHub <#65917>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJIAI57QEXFHJRV3A4MNXTYVEVJLAVCNFSM6AAAAABDXQQLNWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2TCOJXGUYDENA> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[mvdan]

I fully agree with this. I still hear some users talking about their wish for gopls to be faster or more robust, but I have yet to hear about any pain relating to older Go versions.

Perhaps the first release to require Go 1.21 or later could point users to the last gopls version supporting older Go versions, which could be useful as a temporary fallback.

[findleyr]

I fully agree with this. I still hear some users talking about their wish for gopls to be faster or more robust, but I have yet to hear about any pain relating to older Go versions.

@mvdan thanks for that evidence. I think we may hear about some pain related to this, if we really are requiring 9% of users to take action if they want to upgrade, but I think that inconvenience is well offset by the improved robustness and team efficiency resulting from needing to support building with only the latest Go version.

Perhaps the first release to require Go 1.21 or later could point users to the last gopls version supporting older Go versions, which could be useful as a temporary fallback.

We'll definitely do that. We also have a practice of warning folks interactively from the (N-1)st gopls version when their Go version will be dropped by the Nth gopls version.

[gopherbot]

Change https://go.dev/cl/578039 mentions this issue: gopls: use static hooks rather than optional hooks