chore(deps): compatibility with at least two major versions of Go

[Tiscs]

References to other Issues or PRs

Revert #5265, maintain compatibility with at least two major versions of Go.

Have you read the Contributing Guidelines?

Yes

Brief description of what is fixed or changed

I think a module that is so widely used should be compatible with at least two major versions of Go, not just the last one.

thank you.

Other comments

[johanbrandhorst]

I think this change should be the only one necessary to allow the last two major versions, right? It's fine for us to use 1.24 in most of our own testing and so on. Could you revert the other changes please?

[Tiscs]

Whether tests should be run on the minimum supported version of Go?

[ahrtr]

I think this change should be the only one necessary to allow the last two major versions, right?

Yes, It's true.

Could you revert the other changes please?

For other changes, it isn't a big deal to me, but personally I think it'd better to keep the go minor version consistent across the repo.

[ivanvc]

For context, Go has support for the latest two minors: https://go.dev/doc/devel/release#policy. So, for widely used libraries I agree that it ++ideally++ (of course at the maintainer's discretion ;) should stay in the oldest supported version (i.e., 1.23 in this case).

[Tiscs]

Task CI / gorelease (pull_request) fails because the github.com/grpc-ecosystem/grpc-gateway module already requires Go 1.24.

[ahrtr]

If the suffix ".0" wasn't automatically added by go mod tidy, then we should prefer to 1.23. You can also add toolchain go1.23.6 if you want.

Suggested change

	go 1.23.0
	go 1.23

[Tiscs]

This because the go version of package google.golang.org/genproto/googleapis/rpc is declared as 1.23.0, so 1.23.0 should be the minimum version available here.

[ahrtr]

OK, then it's automatically added by go mod tidy. (It's like a virus we can't stop it spreading). Technically, I don't think there is any difference between go 1.23 and go 1.23.0; but Semantically, go 1.23.x means it requires the minimum go patch version for the downstream modules.

I don't know what motivate some people to add the suffix ".0". On the other hand, the golang team should treat the go 1.x.0 equivalent to go 1.x, and do not require the downstream module to add the suffix no matter the upstream has it or not.

[Tiscs]

Starting in Go 1.21, the go directive in the go.mod file supports specifying minor versions, enhancing versioning precision while maintaining backward compatibility.
Setting it to 1.23.0 means that downstream modules must use a Go higher than 1.23.0(e.g. 1.23.6, 1.24.0), not just 1.23.0.

[ahrtr]

The problem is that grpc-ecosystem doesn't have long-term supported versions or stable versions (stable versions should go with the older supported go minor version, i.e. 1.23 for now); its version number has always been increasing linearly.

[Tiscs]

The problem is that grpc-ecosystem doesn't have long-term supported versions or stable versions (stable versions should go with the older supported go minor version, i.e. 1.23 for now); its version number has always been increasing linearly.

Yes, but I think the dependent Go version should not be increased unnecessarily. The new features in Go 1.24 are not used in the project, and the choice should be given to downstream modules as much as possible.