[Proposal] Go language version support

[mx-psi]

Overview

Given recent efforts to reach v1.0.0 (see #4752) and the recent move towards being more explicit about breaking changes (see #4712) I think this is a good time to consider Go language version support of the Collector code when used as a library, since this is 'sort of' a breaking change (although one commonly ignored even when following semver), and since there have been discussions in the past about the use of new Go features (e.g. generics or Go workspaces).

There are two different but related Go versions to consider here: one is the minimum Go version supported for using the Collector as a library and the other is the Go version used to build the official binaries. This can be addressed separately: Go tooling honors the Go version declared in the go.mod file.

Questions to decide

1. What should the policy be for the minimum Go version supported when using the Collector as a library?
2. What should the policy be for the Go version used to build the official binaries?

Points to consider

• Security: the Go version used to build the binaries should not have known security vulnerabilities. We should be able to quickly move to a new version if a security-related bugfix version is released.
• Stability: the Go version used to build the binaries should be as stable as possible. Initial releases of a Go minor version cycle may be less stable than more mature ones, specially when it comes to less used platforms.
• Availability of new language features: new Go versions may have features that are interesting from a development point of view. Use of this features would (usually) mean dropping support for older Go versions.
• OS support: Go drops support for older platforms on minor versions. How long to support a given operating system may have different answers by the OpenTelemetry community than whatever the Go team chooses.
• Testing burden: Supporting more Go versions means testing them on CI, which increases the testing burden.

Prior work

Relevant prior work includes open-telemetry/opentelemetry-go#2379, where the opentelemetry-go library chose to (roughly) follow Go's release policy. The precedent of #3887 is also relevant, where the version was bumped to Go 1.17 because of a security issue that was not fixed by the Go team on 1.16.

Proposal

My proposal is to answer the questions as follows:

1. For the minimum Go version supported when using the Collector as a library, follow opentelemetry-go's approach and stick to Go's release policy (see their README for their specific wording).
2. For the Go version used to build the official binaries, use a supported Go version that does not have known security vulnerabilities (this is mainly to address cases like the vulnerability addressed on Upgrade to Go 1.17 #3887, where a security fix was not backported to a supported Go version).

[codeboten]

The policy used by otel-go makes sense to me, I would be happy to support the same policy for the collector/collector-contrib.

[tigrannajaryan]

For the minimum Go version supported when using the Collector as a library, follow opentelemetry-go's approach and stick to Go's release policy (see their README for their specific wording).

@mx-psi I do not fully understand their wording. Can you expand here?

For the Go version used to build the official binaries, use a supported Go version

What does "supported" mean? Supported by whom?

[mx-psi]

What does "supported" mean? Supported by whom?

Supported by the Go team as defined in https://go.dev/doc/devel/release#policy

[mx-psi]

We discussed this on the February 16th Collector SIG meeting, where @Aneurysm9 gave some details on opentelemetry-go's approach. I will wait until next week for approvers and other community members to voice their opinion here and open a PR then to nail down the wording and figure out if we want to do the Go bump in lockstep or not.

[jpkrohling]

I'm happy with opentelemetry-go's approach. If it turns out to not work for our case in the future, we can always tweak our policy.