@roidelapluie Could you please let me know what you think?
I also need some help guidance with tests on circleci (it seems they failed because of a network error) and I have local issues with the tests too:

level=error msg="failed to read meta.json for a block during repair process; skipping" dir=/var/folders/... err="open /var/folders/.../meta.json: no such file or directory"

At first glance we should accept both versions.

@roidelapluie Does this mean that you want to include every version in the Accept header or omit the version since the server should accept them?

Edit: OpenMetrics specs mandates 1.0.0 for the Content-Type.

Yes, we would need to accept both 0.0.1 and 1.0.0 for a transition period, during which we update the official instrumentation libraries to 1.0.0.

cc @brian-brazil what is your opinion here? Do you agree?

Right now only 0.0.1 is accepted and if you want to support both for a transition period, I would recommend adding both versions to the Accept header keeping 1.0.0 higher in priority, I modified my changes accordingly.

It can be straight switched to 1.0.0, and a confirming OM server can always return 1.0.0.

This is a holdover from initial development, no need to complicate things.

It can be straight switched to 1.0.0, and a confirming OM server can always return 1.0.0.

This is a holdover from initial development, no need to complicate things.

It means that people who have already switched to openmetrics in client_golang and client_python will see different metric names and buckets?

It means that people who have already switched to openmetrics in client_golang and client_python will see different metric names and buckets?

No, the negotiation doesn't look at the version as that's not needed yet.

It means that people who have already switched to openmetrics in client_golang and client_python will see different metric names and buckets?

No, the negotiation doesn't look at the version as that's not needed yet.

https://github.com/prometheus/common/blob/c4fba801dbbe8a6a7c56cbd867f5ec33d63bc172/expfmt/encode.go#L102

I think it does...

Ah, that shouldn't be checking that. Python and Java purposely don't to avoid just this sort of thing delaying the OM rollout. That needs to be fixed in common.

it seems to me that we would need to accept both or keep the status-quo for the time being.

What would be the benefit of querying anything other than 1.0.0 (at the moment) knowing that OpenMetrics specs mandates 1.0.0 for the Content-Type?

@roidelapluie @brian-brazil What do you think can we move this forward? Right now the version is 0.0.1 which as far as I understand is wrong (OpenMetrics specs mandates 1.0.0).
We have two options:

• 1.0.0 only (OpenMetrics specs mandates 1.0.0)
• 1.0.0 and 0.0.1 (to be backward-compatible if necessary)

I think any of these are better than the current behavior that does not comply with the current OpenMetrics specs.

👍🏼
To try to bring context back to this PR I'll link #10074 (comment)
That's the relevant part to this conversation.

Reasoning is the today if a Client is working today it's because it's processing Accept headers and when it sees Open Metrics (with or without the version) it works.

Also today Prometheus successfully processed metrics coming from these Clients.

The only caveat to me would be that theres major changes to how OM format is processed/validated before "true 1.0.0" is achieved in which case when we receive from a Client back. However that is something that should be handled if a change happens. That thus far has not been mentioned.

I will test this with caddy then merge

Thanks!