[prometheus] Stabilize SDK exporter temporality

[johannaojeling]

Fixes #4983

Changes

Moves Prometheus Metrics Exporter spec Temporality status from Development to Stable. Implemented by 3+ SDKs.

• Related issues Stabilize Prometheus Metrics Exporter spec: Temporality #4983
• Related OTEP(s) #
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
  • For trivial changes, include [chore] in the PR title to skip the changelog check
• Spec compliance matrix updated if necessary
• Declarative config data model is updated if SDK config surface is changed

[johannaojeling]

@open-telemetry/prometheus-interoperability

[jack-berg]

I don't see anything wrong with this, but have a meta comment:

Its odd to break apart the stabilization effort of the SDK exporter into such small pieces. As a maintainer reviewing this spec, I don't know when I can/should consider making the prometheus exporter I maintain stable. With this PR, there's just one portion which is stable, and I clearly can't publish a useful stable component if that's the only thing I'm allowed to stabilize. But when does the document reach a critical mass? Idk!

Previously when we've had documents with mixed stability status, we've been opinionated about the bounds for what that critical mass is: The doc starts as all experimental, and in on atomic PR, we stabilize all of it explicitly calling out the pieces which aren't quite ready yet. With this type of approach, its easy for me as a maintainer: the spec is stable with some exceptions, so I can stabilize my component with some exceptions.

If we're going to go with this "stabilize in small chunks" approach, can the @open-telemetry/prometheus-interoperability group provide some guidance on when they think the document has reached critical mass such that maintainers can consider stabilizing their implementations?

[jack-berg]

If we're going to go with this "stabilize in small chunks" approach, can the @open-telemetry/prometheus-interoperability group provide some guidance on when they think the document has reached critical mass such that maintainers can consider stabilizing their implementations?

In practice, the signal could be updating the status from "Mixed" to "Stable, except where otherwise specified", like we do in other places (example).

[ArthurSens]

Hey Jack, we just made this change to make steady progress towards stabilization. Since implementing the whole spec at once is a lot of effort, we thought breaking it down into smaller pieces would make it easier to coordinate with SDK maintainers and for us to handle the "Project management" part.

I haven't discussed with @dashpole yet, but in my mind, we would only switch the whole spec to "Stable" once all smaller pieces are declared "Stable," and we have at least 3 SDKs implementing the whole spec. I wasn't planning to declare the whole spec stable while some parts are still in development. That said, I'm happy to have this discussion in case anyone was thinking differently!

[dashpole]

I was planning to move it to **Status**: [Stable](../document-status.md), Unless otherwise specified. once enough of it is stable that you could stabilize a component based on it. Having multiple implementations should be a prerequisite for stabilizing a section.

FWIW I have liked "stabilize in small chunks" because it feels like we get to give each section of the spec the attention it needs. There are also still some "tough decisions" parts of the spec (primarily resource handling in SDK exporters, since entities is likely to require us to change our current approach). It is easier to start by marking the other sections as stable so we can focus on the last remaining few. We will make sure that we communicate with the rest of the community when we have enough stabilized that language maintainers can put out stable exporters.

[jack-berg]

I like the stable in small chunks approach as well.

We will make sure that we communicate with the rest of the community when we have enough stabilized that language maintainers can put out stable exporters.

Great! As long as that's the plan its gets a 👍 from me.