Harold Dost

As requested in the community meeting: I am partial towards Option 2. Specifically I don't think we'd eliminate the API surface as we're currently supporting basically all the needed features...

I guess I'll try to take a look at how we could go for option 3. From the top of my head use cases to look at: - Apps +...

Is that the case ? Start time should be the first point in time something existed End time is usually when the datapoint was recorded. And https://github.com/open-telemetry/opentelemetry-proto/blob/c5c8b28012583fda55b0cb16f73a820722171d49/opentelemetry/proto/metrics/v1/metrics.proto#L176 I would imagine...

> > Is that the case ? > > > > Yes. Every datapoint/metricpoint(time-series) in the same metric has same start/end time for a collection. Start time isn't intended to...

Perhaps for sum its not an issue since we are just adding all structures together, but if in a collection for a histogram you need to aggregate latencies. The observation...

Yes i would agree that we don't want to bump the compiler if we do the have to, but that the ceiling for that should be lower than just 3...

Ah so in this case we can also avoid this conflict for env_logger at least by not caring about the examples.

It appears a similar conversation is happening in the spec https://github.com/open-telemetry/opentelemetry-specification/issues/1196

See https://github.com/open-telemetry/opentelemetry-rust/issues/1554

@thorhs There's been quite a few large changes recently. If you feel comfortable you could rebase/cherry pick onto main, or if you don't mind one of the maintainers can take...