Tracing Specification Release Candidate + GA Planning

As we’ve discussed in past announcements, we’re hard at work building towards OpenTelemetry’s first GA release. Since the beta release in March, OpenTelemetry has resolved 2,640 github issues and merged 5,721 PRs making it the second most active CNCF project. Today marks another milestone in this journey, with the freezing and first release candidate of the tracing specification.

Tracing Spec Release Candidate

The tracing specification is now frozen and considered to be a release candidate (RC). The OpenTelemetry language APIs and SDKs have a stable tracing specification to build their own release candidates against. This means:

• API, SDK, and Collector release candidates that implement the tracing specification will appear within the next few weeks.
• No breaking tracing spec changes are allowed between now and the final GA specification, beyond any showstopper (P1) issues that are revealed in the RC period. We don’t expect any of these to appear, but the purpose of the RC period is for us to validate that we have a GA-worthy spec.
• Some non-breaking changes will be allowed during the RC period. Most of these are clarifications of existing behaviour or simple editorial updates.

The release candidate sections of the specification include all tracing related dependencies, specifically the following sections: Trace, Baggage, Resource, Context Propagation, Environment Variables, and Exporters (for traces). You can view the progress of each OpenTelemetry component’s implementation in the project status matrix.

What’s Coming Next?

Achieving a release candidate of the tracing specification has been the top priority of OpenTelemetry since releasing our beta in March. With this completed, our focus now shifts to RC tracing implementations of the APIs, SDKs, Collector, and auto instrumentation components, as well as producing a release candidate of the metrics specification.

RC Tracing Implementations

Most OpenTelemetry APIs and SDKs are close to completing their RC tracing implementations, and we expect the first wave of these to arrive within the next two weeks. Contributors who are looking to provide instrumentation (for various web frameworks, storage clients, etc.) can start building against release candidate APIs once they arrive. While the APIs may change in response to issues discovered during RC usage and testing (which will result in multiple pre-GA release candidates for these components), these will be extremely constrained.

The SDKs may have two waves of RC milestones.The first will contain functionality from the tracing and context propagation sections of the specification, and the second will include RC implementations for baggage, exporters, resources, and environment variables.

Metrics

In parallel to the tracing RC component releases, we will apply the focus that we’ve had on tracing to the metrics specification. Starting this week, we will prioritize metrics-related changes to the specification for the next specification milestone. Shortly after this, the APIs, SDKs, Collector, and other components will publish releases with RC-quality tracing and metrics functionality.

Productionization and GA Readiness Work

Once the metrics specification, SDKs, Collector, and other components reach release candidate status, we will focus on productionization tasks like writing documentation, producing a post-GA versioning strategy, building additional automated tests, etc. Once we are satisfied with each component’s progress of adoption and feedback from adoption, we will announce their general availability.

Overall Timeline

1. The tracing section of the specification achieves RC quality and is frozen (this is today’s announcement)
2. Components (APIs, SDKs, Collector, auto instrumentation, etc.) issue release candidates with RC-quality tracing functionality
3. The metrics section of the specification achieves RC quality and is frozen
4. Components issue release candidates with RC-quality tracing and metrics functionality
5. Once we are satisfied with our metrics + tracing release candidates, OpenTelemetry goes GA
6. Logging enters beta, then issues an RC specification, followed by RC-quality logging functionality in each component, followed by a GA for logging

We will have a better understanding of our GA release timeline in the coming weeks once outstanding work on the metrics specification is fully accounted for.

Tracking a Language’s Progress

In addition to the project status matrix, each component’s implementation has their own github project to track progress, e.g. JavaScript, Java, Go, Python, .NET, and Java auto instrumentation.

FAQ

I want to use OpenTelemetry on my production services; what’s the impact of today’s announcement?

SDKs with release candidate quality tracing support will be available in a few weeks. Release candidates are not recommended for critical production services, however they are functional and are intended to offer APIs that are compatible with their upcoming GA counterparts.

I want to write instrumentation for OpenTelemetry; what’s the impact of today’s announcement?

APIs with release candidate quality tracing support will be available shortly (prior to the SDKs). You can bind against these to produce traces that will be picked up by the OpenTelemetry SDKs or any other implementations of the OpenTelemetry APIs.

When will OpenTelemetry offer drop-in replacements for OpenCensus and OpenTracing?

Work is currently underway on bridge APIs that allow OpenTelemetry SDKs to seamlessly replace OpenCensus libraries or OpenTracing implementations. While the delivery date of this functionality is not tied to OpenTelemetry’s GA goals, we expect this to arrive between each API + SDK’s release candidate and GA milestones.

Wrapping Up

Producing a specification release candidate is an important milestone for the OpenTelemetry community, and it took significant effort on the part of our contributors to make this happen. We’d like to thank every person and every organization that was a part of this release, and to recognize that their contributions are laying the groundwork for the project’s long term success.

Organizations that have provided major development support to OpenTelemetry include (in order of commits) Splunk, Microsoft, Google, Lightstep, Dynatrace, New Relic, Infostellar, Toptal, Red Hat, Shopify, Zillow, Kinvolk, Postmates, Uber, Honeycomb, Out There Labs, NCR, MailChimp, Datadog, Reelevant, Volkswagen, Transit, Amazon (who announced their support today), and the City of Montreal. The full list of contributing organizations is tracked on our Dev Stats site. We’re grateful to these companies for investing in the project, as we know that engineering time is incredibly expensive; the fact that so many of these firms see value in contributing to OpenTelemetry is a testament to the project’s impact across the industry.

If you haven’t been a part of the OpenTelemetry community but would like to join, now is the perfect time! OpenTelemetry is now in the top three CNCF projects by weekly and cumulative commits, and no matter your level of commitment (ha!) to the project, contributions are always welcome. If you have a particular area that you’re interested in (for example, the Python API + SDK), the best way to get involved is to join the relevant weekly SIG meetings or interact with other contributors on Gitter.