search

prometheus / common

Go libraries shared across Prometheus components and libraries.
Apache License 2.0
259 stars 306 forks source link

Add support for go 1.20 #617

Closed ArthurSens closed 2 months ago

ArthurSens commented 2 months ago

Since https://github.com/prometheus/common/pull/590 (released in v0.49.0), common doesn't work for go 1.20 or lower versions since it uses functions that are only available since go 1.21.

Several features that do not require go 1.21 were introduced in common, but cannot be used by downstream projects that are still stuck with go 1.20 for a while, e.g. client_golang that wants to use the new OpenMetrics created timestamps and units.

This PR rescues the old implementation of LabelSet.String() under build tags. When using 1.20, common would still work even without the optimizations made in https://github.com/prometheus/common/pull/590

bboreham commented 2 months ago

Not directly relevant to that PR, but we should call out where we do support older Go versions. I was under the impression Prometheus supported "last two versions" only, same as the Go project itself.

ArthurSens commented 2 months ago

Not directly relevant to that PR, but we should call out where we do support older Go versions. I was under the impression Prometheus supported "last two versions" only, same as the Go project itself.

This PR is focused on enabling client_golang, which promises support for the 3 latest versions. I joined the team after this decision was made, I don't know the reason behind it, to be honest.

Happy to discuss if that makes sense to you @kakkoyun and @bwplotka

kakkoyun commented 2 months ago

Not directly relevant to that PR, but we should call out where we do support older Go versions. I was under the impression Prometheus supported "last two versions" only, same as the Go project itself.

Has this changed recently? I was under the impression that the upstream Go supported the latest three major versions. Thus, client_golang supports the same. We should always follow the same upstream release policy.

This was a rule that was in place before @bwplotka joined the team.

If Go didn't change the release policy after this rule was implemented, there could be another historical reason behind it. @beorn7, I'm curious: Does this ring any bells?

bboreham commented 2 months ago

client_golang, which promises support for the 3 latest versions

Where is this written down, please?

kakkoyun commented 2 months ago

client_golang, which promises support for the 3 latest versions

Where is this written down, please?

https://github.com/prometheus/client_golang/blob/e133e490296d2ff915bfc23cdec87c235ad36ef3/README.md?plain=1#L14

beorn7 commented 2 months ago

I don't think the support promise was ever modeled on promises by any support for older Go version by the Go team. It might have just been a rule of thumb we made up, knowing from experience that many users must use older Go toolchains for one reason or another, even if that isn't a good situation to be in.

But rules can be changed if they don't seem useful anymore.