Bump module required go version

[sunjayBhatia]

The README mentions it should be used with any one of the three latest major releases. (link)

This change bumps the minimum go version to 1.15 as currently 1.17 is
the latest major release.

RELEASE NOTES:

• Bump required Go version to 1.15 as per README prerequisites

[dfawley]

I'm not sure there's much value in this change by itself. If the code still compiles on 1.14, I don't see a strong reason to artificially restrict ourselves to 1.15+ yet. What is the underlying motivation for this?

[sunjayBhatia]

I'm not sure there's much value in this change by itself. If the code still compiles on 1.14, I don't see a strong reason to artificially restrict ourselves to 1.15+ yet. What is the underlying motivation for this?

• The README mentions the latest 3 major releases of Go as prerequisites, 1.14 falls out of that now
• go-control-plane is bumping to 1.16+ as minimum required (see Update go build version to something current envoyproxy/go-control-plane#532), motivated by the Go support policy being N-1
  • In case new language features get used in go-control-plane or other deps, we dont want to surprise/break grpc-go

[dfawley]

go-control-plane is bumping to 1.16+ as minimum required (see Update go build version to something current envoyproxy/go-control-plane#532), motivated by the Go support policy being N-1

Is there any specific thing triggering the desire to change it now? If you take this policy in go-control-plane, then gRPC-Go will need to always be using an older release -- which means any updates to the protos in the main envoy repo will not be accessible to gRPC-Go for at least 6 months.

[sunjayBhatia]

go-control-plane is bumping to 1.16+ as minimum required (see Update go build version to something current envoyproxy/go-control-plane#532), motivated by the Go support policy being N-1

Is there any specific thing triggering the desire to change it now? If you take this policy in go-control-plane, then gRPC-Go will need to always be using an older release -- which means any updates to the protos in the main envoy repo will not be accessible to gRPC-Go for at least 6 months.

I think just a due diligence thing, but @jpeach would have to answer that one if theres something more specific

[jpeach]

go-control-plane is bumping to 1.16+ as minimum required (see Update go build version to something current envoyproxy/go-control-plane#532), motivated by the Go support policy being N-1

Is there any specific thing triggering the desire to change it now? If you take this policy in go-control-plane, then gRPC-Go will need to always be using an older release -- which means any updates to the protos in the main envoy repo will not be accessible to gRPC-Go for at least 6 months.

I think just a due diligence thing, but @jpeach would have to answer that one if theres something more specific

Yeh, it's about not being to far (we were on Go 1.11, which has different modules defaults IIUC), and being on a supported Go release. If it's going to cause unnecessary churn across the ecosystem, we ought to accommodate that, but I do think that being on a supported stack is desirable.

[jpeach]

If you take this policy in go-control-plane, then gRPC-Go will need to always be using an older release -- which means any updates to the protos in the main envoy repo will not be accessible to gRPC-Go for at least 6 months.

FWIW, I think that there is general support in the community for separating the proto definitions out from the go-control-plane implementation. Needs some bazel and CI expertise to make that happen.

[dfawley]

FWIW, I think that there is general support in the community for separating the proto definitions out from the go-control-plane implementation. Needs some bazel and CI expertise to make that happen.

This would be great to do before such a change. Providing those protos should be done with as old a Go language version as feasible, since they are very basic and fundamental definitions. This is envoyproxy/go-control-plane#391. We could afford to import an older version of the rest of the repo if needed.

Also note that there is a difference between "not supported" and "explicitly made to prevent". With our current go.mod, grpc-go probably works with 1.14, even though we don't support it (in the sense that if a bug is discovered that only manifests on 1.14, we may choose not to fix it). With this PR, we would actively be breaking 1.14 users that may have been able to run previously.

[sunjayBhatia]

noticed that the testing workflows explicitly check this code compiles on the latest 3 Go releases, so CI should catch a bump to go-control-plane that breaks grpc-go, thats maybe a better check than this change tbh, willing to close given that exists

grpc-go/.github/workflows/testing.yml

Lines 45 to 67 in afded72

	- type: vet+tests
	goversion: 1.17
	- type: tests
	goversion: 1.17
	testflags: -race
	- type: extras
	goversion: 1.17
	- type: tests
	goversion: 1.17
	goarch: 386
	- type: tests
	goversion: 1.17
	goarch: arm64
	- type: tests
	goversion: 1.16
	- type: tests
	goversion: 1.15

[dfawley]

CI should catch a bump to go-control-plane that breaks grpc-go

Because of modules, no change in go-control-plane will break us until we update our version of gcp that we use.

[sunjayBhatia]

CI should catch a bump to go-control-plane that breaks grpc-go

Because of modules, no change in go-control-plane will break us until we update our version of gcp that we use.

Yeah, if there were a change that broke compilation on say go 1.15, the PR to bump go-control-plane would go red and we could address it then

[dfawley]

OK, I will close this PR then.

My recommendation would be to bump the version in your go.mod only when you take advantage of language features that require it, not to reflect your support policy.