Should you be updating the min go version so quickly?

[ansel1]

It seems that this library adopts the latest go version as a minimum very quickly, forcing consuming projects to upgrade their go version too, or to stay with older versions of this library.

A pattern I've seen in other low-level libraries, which are consumed by many other projects, is to be conservative about how quickly they require newer versions of go.

[dmathieu]

We follow the Go release policy: https://go.dev/doc/devel/release#policy
Supporting Go versions that aren't supported anymore doesn't make a lot of sense. It also prevents us from iterating properly (for example, the otelhttp auto-instrumentation can't support mux route patterns from 1.22 until 1.21 is removed from support).

If you wish to be conservative with the version of Go you're using, maybe you want to do the same with the otel version you're using, and old versions don't disappear.

[pellared]

Moreover, I do not thing it is good to support versions that are no longer unsupported and are known to have bugs (including security vulnerabilities).