Bartlomiej Plotka

Nice, good point. It feels we have to make `buf.ReadFrom` go routine context aware: ``` var buf bytes.Buffer _, err = buf.ReadFrom(resp.Body) body = buf.Bytes() close(done) ``` Help wanted!

> Perhaps we shouldn't have it in common. We could/should reduce the friction to creating new repos for Go libraries that don't need to be in common. Agree. Maybe we...

One alternative is for client_golang to stop depending on prometheus/common which might be the desired outcome here. We could vendor what we need if API stability is not on the...

If anyone is interested on why stability of Go libs is essential, feel free to read a short story from @dims on k8s channel: https://kubernetes.slack.com/archives/CHGFYJVAN/p1741621071818569

Just linking another argument for v1. By chained dependency, stable Otel Go SDK depends on stable client_golang which depends on unstable common which causes [some deprecation risks](https://github.com/open-telemetry/opentelemetry-go/pull/6590#issuecomment-2789184916).

Another data-point: https://github.com/kubernetes/kubernetes/issues/133878

Discussion: https://cloud-native.slack.com/archives/C01AUBA4PFE/p1756921591447069

We chatted about this in client_golang maintainers sync.. I think we would love to maintain a stable version of code for the pieces client_golang depends and ensure client_golang does not...

@SuperQ > I think it might be better to move expfmt to it's own repo. Yup, that's a solid option, but it's generally more expensive to maintain and have some...

It's not about recent changes but intention. Are we sure other parts have an API that we can maintain in stable manner? One example for other packages was `promlog`. It...