Release v1.0.0

[tedsuo]

This pull request versions the OpenTelemetry specification to v1.0.

If there are any open PRs or issues which you believe would block this merge, please list them here.

Remaining issues marked as required for tracing GA can be found here: https://github.com/open-telemetry/opentelemetry-specification/issues?q=is%3Aopen+label%3Arelease%3Arequired-for-ga+-label%3Aspec%3Ametrics+label%3Apriority%3Ap1

[Oberon00]

Before we release 1.0 don't we need to feature-freeze tracing and resource SDKs at least?
Also, I think we need to put something like "Document status: working draft" into non-GA specification, to avoid misrepresentation of these as GA. EDIT: Maybe we should even make a release/1.0.x branch where we delete all the non-GA parts.

[tedsuo]

Tracing and resources don't need to be frozen in general, but future changes will need to be backwards compatible once components are marked as stable. Are there breaking changes coming to those components? I didn't see them in the spec project.

I agree that we should clearly and consistently mark every document in the spec as stable or experimental.

I'm not sure that a separate branch would be helpful... keeping it in sync sounds annoying. I think we need to educate spec readers (and users in general) about the singal lifecycle and get people comfortable checking components for their level of stability.

[carlosalberto]

In theory we need to get the issues that have been triaged as Required, minus the Metrics portion: https://github.com/open-telemetry/opentelemetry-specification/issues?q=is%3Aopen+is%3Aissue+label%3Arelease%3Arequired-for-ga+-label%3Aspec%3Ametrics+

An additional question is whether we need, for this specific release, the OT compatibility part (which is on the works although, hopefully, very close to be completed). Likewise, a question stands for the OC case.

[tedsuo]

Thanks @carlosalberto I updated the links.

IMHO, OT and OC compatibility can be marked as optional for v1.0, as adding them is not a backwards incompatible change. There has been almost no work on the OC front, so it is not a reasonable requirement.

[yurishkuro]

IMHO, OT and OC compatibility can be marked as optional for v1.0, as adding them is not a backwards incompatible change.

Except that it has the bad optics of being the 15th standard. Compatibility was explicitly called out as one of the success criteria of the new project.

[carlosalberto]

@yurishkuro My hope is that this week or the next week we finish the OT part (which, I'd imagine, is a MUST by the time Metrics is also available). Agreed that otherwise we would have missed a point.

For the record: the OT compatibility part is a high priority item for me in the following weeks ;)

[tedsuo]

@yurishkuro I don't intend to say we are not backwards compatible, just that we don't need it required until both tracing and metrics are completed.

[tedsuo]

@Oberon00 Added lifecycle statuses to each document, and bumped the relevant documents to stable: #1385

[jsuereth]

edit: OT vs. OTel confusion on my part.

@yurishkuro Regarding OTel=>OC compatibility (and vice versa), you can see the pending specifciation #1332 in place now. For the purpose of 1.0 of Trace, we think that specification represents the best-compatibility guarantees we can provide OTel<=>OC compatibility. While there are some details that diverge, it's compatible in the 80% case.

My team has been working on OC=>OTel compatibility. Metrics stability has been a major blocker to anything concrete, but there should be working (and we can keep them stable) shims for Go + Java with Trace + 1.0.0. We are (currently) looking into ripping the shim apart into two components (without requiring another OC release).

In any case, I think the real point here is to understand if we agree Trace 1.0.0 is ready as-is and we can provide the OT<=Otel=>OC bridges we need.

[yurishkuro]

@jsuereth I think you are using OT to mean OpenTelemetry (please don't, the agreed abbreviation is OTEL/OTel, whereas OT stands for OpenTracing), so if you're asking about OTEL-OC interop then I am not the right person to ask since I never used OC.

[jsuereth]

@yurishkuro Sorry!, at work everyone refers to OTel as OT, will fix that in the future. My point was more about whether OT=>Otel/OC=>Otel compatibility could be spec'd. There's also an OT<=>OTel spec in progress. I'm not aware of the details, but are we concerned that we wouldn't be able to implement a bridge?

[yurishkuro]

@carlosalberto was working on the OT bridge and spec.

[alolita]

My understanding for the official abbrevation is also OTEL or OTel as @yurishkuro pointed out.

@jsuereth please see https://github.com/open-telemetry/community/blob/main/marketing-guidelines.md

Do you think there is a need for a project glossary? There are a lot of abbreviations used in the project docs and maintainer speak. The context can be confusing for contributors joining the project.

[cijothomas]

My understanding for the official abbrevation is also OTEL or OTel as @yurishkuro pointed out.

@jsuereth please see https://github.com/open-telemetry/community/blob/main/marketing-guidelines.md

Do you think there is a need for a project glossary? There are a lot of abbreviations used in the project docs and maintainer speak. The context can be confusing for contributors joining the project.

https://github.com/open-telemetry/opentelemetry-specification#acronym

[alolita]

thanks @cijothomas

[reyang]

LGTM assuming the release date in CHANGELOG will be updated.

[andrewhsu]

LGTM

[carlosalberto]

@open-telemetry/specs-approvers Please review so we can proceed 🍾

[bogdandrutu]

Moved the date to Monday since @open-telemetry/technical-committee did not approve it (we need one more to have at lest half of the members +1)

[bogdandrutu]

I will wait few more hours then merge this.

[Oberon00]

Sorry to raise two more (related) potential blockers:

• I think we'll want to decide on / merge Update ottrace environment variable to match spec. #1406 first ✔️
• https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md is lacking a document/lifecycle status (was it missed in Add lifecycle statuses to all documents #1385?)

[carlosalberto]

I think we'll want to decide on / merge #1406 first

Merged it as this is merely a follow up (and I guess I can make the call, given it's an identifier related to OpenTracing ;) )

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md is lacking a document/lifecycle status (was it missed in #1385?)

Oh yes, I had already mentioned it to @tedsuo . Let's do a tiny follow up to do that, and we can release 🎆

[tedsuo]

@Oberon00 @carlosalberto added stable to ENV VARS: #1409

[dyladan]

The trace id ratio based sampler still has "TODO: Add details about how the TraceIdRatioBased is implemented as a function of the TraceID."

Since this is our only sampler that isn't always on or always off, I feel like it should be properly specified before 1.0

[Oberon00]

I created #1412 and alternative #1414 with a suggestion on how to resolve this for now. The after-ga follow-up is #1413.

[tedsuo]

[bogdandrutu]

@open-telemetry/technical-committee and @open-telemetry/specs-approvers and @open-telemetry/specs-trace-approvers are you aware of any blocking issue for this? Otherwise in couple of hours I will do the release