Add lifecycle statuses to all documents

[tedsuo]

Changes

• Adds the current lifecycle stage to each document's status.
• Clarifies that the feature-freeze status is a community process, not a definition of stability or feature-completeness.
• Sets the status for Tracing SDK, Resource SDK, Context, Propagation, Baggage API, Jaeger Exporter, and Zipkin Exporter to stable.

Related issues #

• Release v1.0.0 #1372
• Release v1.0.0 #1373

[bogdandrutu]

Please rebase and checks will run

[tedsuo]

@bogdandrutu resolved

[lzchen]

I know that environment variables are deemed optional in the spec matrix but some languages have already implemented some of them. In this case, will the env var names be marked as "stable" here as well or will there possible breaking changes in the future (such as the recent OTEL_EXPORTERS -> OTEL_METRICS_EXPORTER + OTEL_TRACE_EXPORTER)? We need to know whether or not we can release env var functionality as part of 1.0.0.

[jsuereth]

I know that environment variables are deemed optional in the spec matrix but some languages have already implemented some of them. In this case, will the env var names be marked as "stable" here as well or will there possible breaking changes in the future (such as the recent OTEL_EXPORTERS -> OTEL_METRICS_EXPORTER + OTEL_TRACE_EXPORTER)? We need to know whether or not we can release env var functionality as part of 1.0.0.

I'd be nice if we could lock down the semantics folks were already relying on here without having to fully lock down everything about environment variables. The OTEL_EXPORTERS change was one where we likely WILL be doing deprecation + migration in the future, and we could have done that here for existing SDKs rather than force migrate prior to 1.0.0.

It'd be nice if we agreed to "1.0" environment variables (even if they're optional, we still won't change semantics in breaking ways). so +1 to answering this question.

[tedsuo]

@lzchen @jsuereth I think there are two questions about env vars.

• Have we marked them as stable yet? The answer to that is no.
• Should we mark them as stable? We better do that soon, IMHO.

Since they are currently experimental, I would like to mark them here as such. A separate issue can then be opened to address making them stable. Does that sound good to you two?

[lzchen]

@tedsuo
Discussed during 02/01/2021 maintainer's meeting.
Environment variables that are related to tracing will be marked as stable by the 1.0.0 release.

[bogdandrutu]

There is are discussion in this document about JSON being supported for OTLP/HTTP which I think we are not yet ready to make it stable. How can we solve that?

[tedsuo]

Ok, I marked OTLP/HTTP as experimental. The JSON and binary formats for HTTP were intermixed; if we want proto over OTLP/HTTP to be stable this section should be re-written.

[tigrannajaryan]

OTLP/HTTP-Protobufs are stable. Only OTLP/HTTP-JSON is unstable. Please file a TODO to fix this.

We should probably also note that only Traces are currently stable. Looks like we are going to end up with a lot of clarifications for our stability declarations in this file to be true, but that's the reality.

[tedsuo]

Thanks @tigrannajaryan. I created a follow up issue: #1397

[carlosalberto]

@bogdandrutu Please review. I think that we are ready to merge this and tune the OTLP/JSON part in the related follow up.

[reyang]

[Sachin1O1]

I guess, we need to update the status of the doc again or is it still in experimental?