You've already forked opentelemetry-go
mirror of
https://github.com/open-telemetry/opentelemetry-go.git
synced 2026-06-03 18:35:08 +02:00
David Ashpole
28df982c8b
Part of https://github.com/open-telemetry/opentelemetry-go/issues/8110 Related to https://github.com/open-telemetry/opentelemetry-go/issues/5882. I'm hoping to find a better way to support experimental Options types in our API packages. This is one approach to consider. This contains no public API changes. It introduces a type: `ExperimentalOption` in `/metric/internal/x`, which can be used by our experimental options defined outside of the module. Options that embed this interface are ignored by `New*Config` builder functions in the metrics API to prevent them from panicing when used. Only SDKs that explicitly support the experimental option in question will respect it. Alternative SDKs will ignore the experimental options. We would still need to treat ExperimentalOption as a stable artifact, since the SDK will indirectly depend on it. See https://github.com/open-telemetry/opentelemetry-go/compare/main...dashpole:opentelemetry-go:attributes_advisory for how this would be used to support the advisory attributes parameter.