[Feature]: Do we want to make policy to support N-1 Go version?

[yurishkuro]

Requirement

OpenTelemetry Collector has a policy of being compatible with the last two versions of Go, as common in the Go community.
Since Jaeger code is being imported in OTEL in some places, should we have a similar policy?

Problem

Our recent Go 1.20 upgrade (#4202) broke them since we started depending on Go 1.20 features.

Proposal

• We can upgrade our CI to use new versions of Go when they come out
• But our go.mod would stay on N-1 version to ensure compiler compatibility
• We should enforce that with a CI check

Open questions

• If we do this now, what do we do with incompatible changes, roll them back? Or make the policy effective from the next Go version only?

[yurishkuro]

@jaegertracing/jaeger-maintainers can I get opinions?

[albertteoh]

I agree for Jaeger to stay compatible with the N-1 Go version given that's the common practice in the Go community.

+1 for CI check.

If we do this now, what do we do with incompatible changes, roll them back? Or make the policy effective from the next Go version only?

I don't have a strong opinion on this. I would slightly lean towards making this policy effective from the next Go version, unless if staying on 1.20 is causing significant problems for the OTEL collector.

[codeboten]

Can you confirm whether the policy will be in place following go 1.20? This means the collector dependencies on jaeger will at 1.41 until the collector bumps the version of go it supports.

[yurishkuro]

confirmed

[mx-psi]

Go 1.21 is out, we will be dropping support for Go 1.19 (see open-telemetry/opentelemetry-collector-contrib/issues/25116 for status on this) and the new Jaeger policy will allow us to keep updating Jaeger after this

[yurishkuro]

Booked #4653 to track implementation of the policy

[yurishkuro]

@mx-psi @codeboten fyi #4724