Proposal: Set go.mod Go language version to oldest supported Go version (1.21 currently)

[stapelberg]

Currently, our go.mod specifies Go 1.17, meaning that is the oldest version of Go we support and we cannot use language features from newer versions of Go.

Go’s release policy itself is that the most recent 2 major versions are supported (https://go.dev/doc/devel/release#policy), i.e. currently Go 1.21 and Go 1.22.

@dmitshur has filed a proposal to update the Go version line in the x repositories to go 1.21, and gopls wants to take a similar step. The main reason is that Go 1.21 introduced forward compatibility and toolchain management (https://go.dev/blog/toolchain), meaning all supported Go versions now support toolchain management.

In light of these developments, Go Protobuf’s Go 1.17 version seems too conservative.

I propose that we set the Go language version in Go Protobuf’s go.mod file to the oldest supported Go version, i.e. currently Go 1.21.

Please let me know ASAP if this would be a big problem for your use-case and why.

[jhump]

@stapelberg, we try to support one add'l release of Go, so we'd appreciate pinning no more recent than Go 1.20, just so we can continue to support Go 1.20 for our own libraries and be able to update to the latest/next release of protobuf-go.

I might also point out that the other major Go libraries, like those in golang.org/x/... all seem to pin 1.18, which a few pinning 1.19. If those packages provide broader support, it seems like it would be valuable for Protobuf to provide the same board support.

Any change you could tweak the recent change to step it back to 1.20 from 1.21?

[jhump]

FWIW, our desire to support one add'l version back mirrors Amazon's support policy with its AWS client libraries for Go: https://github.com/aws/aws-sdk-go-v2?tab=readme-ov-file#go-version-support-policy

I think it is a pretty common stance to want to support one or two prior versions of Go. And since protobuf-go is such a heavily used dependency, it would be a much friendlier stance for projects with dependencies on protobuf (even indirect/transitive) to provide a little more room with regards to the support window.

[dmitshur]

@jhump Thanks for your comment. I want to address the second paragraph in #1613 (comment): the golang.org/x/... modules are only tested with the 2 most recent versions which are supported per Go's policy, not older. Their go directive values are not a good source to infer support from. That directive hasn't been updated regularly to use newer semantics because it has been a manual process thus far, last done holistically in golang/go#60268. As the original issue points out, we plan to work towards automating that process.

The Go project officially supports only the 2 most recent major versions as written down at https://go.dev/doc/devel/release#policy, and the Go proposal process would be the best place to suggest a change to that policy. Thanks.

[perezd]

I noticed that Go is, unfortunately, missing from Protobuf's version support policy listed here:
https://protobuf.dev/support/version-support/

Dropping/changing the support minimums for Go versions feels like a breaking change that would merit a major release to signal such a change. Is that the plan?

Reviewing the compatibility statements of the project README:
https://github.com/golang/protobuf?tab=readme-ov-file#compatibility

This change doesn't seem to reflect any of the stated valid reasons for a breaking change. Was this announced to the mailing list? I believe this requires a 6-month heads-up per the stated policy.

I appreciate the interest in following the supported policies of Go releases, but as far as I can tell, this isn't actually something that is inherently required or guaranteed to be the case for this project. Am I misunderstanding?

[stapelberg]

Thanks for your feedback.

@jhump We can consider adding support for one extra deprecated Go version (Go 1.20 in this case) if this really helps large parts of the ecosystem. We wouldn’t want to go back any further than one deprecated version, though.

Before we make that change, can you explain where the motivation comes from, both in the AWS case (do AWS users have trouble updating to newer Go versions?) and in the buf.build case (are your customers actually reliant on deprecated Go versions?), just so that we can better understand and justify this extra work/delay?

Also, can you explain if this situation is expected to improve thanks to the toolchain management features of Go 1.21+, or are you expecting to be perpetually behind the support window?

@perezd No, I don’t think it’s reasonable to treat a language version bump as a breaking change in Go modules. Bumping to v3 will cause incredible ecosystem churn. Ask around among buf.build folks regarding the v1→v2 transition. IIRC, it was someone from buf.build who even asked us to never do a major bump like that ever again.

[perezd]

No, I don’t think it’s reasonable to treat a language version bump as a breaking change in Go modules.

I understand your position. Thanks for clarifying. My main concern was if people are upgrading their dependencies and (often transitively) protobuf causes their builds to break due to tightening of the supported version window suddenly, would that reflect poorly on the project? It's not totally clear from reading the Protobuf change policy or your docs when someone should expect or be able to plan for changes like this that impact their deployments.

Edit: GCP versions policy refers to three most recent versions fwiw: https://cloud.google.com/go/getting-started/supported-go-versions

[jhump]

Since Protobuf is so heavily used by the GCP Go libraries, I would think that page that @perezd linked above would weigh heavily in decisions like this.

Will GCP be okay with updating their policy or with just not pulling in protobuf-go updates for a few months?

I'm not sure how Amazon and GCP landed on these policies. We landed on it just because, in practice, updating the toolchain every 6 months or every year can be painful. While it might usually be painless and drama-free (that's obviously the Go team's intent), there could be other logistics to consider (like if an organization has a monorepo that doesn't support multiple versions of the toolchain, in which case extra testing and coordination is necessary for each update, perhaps from a dedicated developer productivity team). While the updates have recently been very smooth, I certainly remember past Go upgrades that were not (like updating to Go 1.7 and then Go 1.13 at past employer).

The toolchain improvements in Go 1.21 may indeed change our thinking on this. But since we haven't updated our own libraries to that point yet (they all still support Go 1.20), we haven't given it as much thought.

[stapelberg]

Thanks for the details, folks. I agree that we should align with large users such as the GCP Go libraries.

It might make sense to revisit this once toolchain management is used more in practice. When revisiting, we should first figure out if libraries like GCP Go and AWS can be aligned with Go’s support policy (only 2 versions) before updating Go Protobuf.