GA Planning

The maintainers SIG is coordinating the RC and GA releases. Please contact Morgan McLean, Ted Young, and Andrew Hsu if you have any questions.

We’re aiming to make OpenTelemetry generally available in 2020, along the following stages:

• GA release candidate(s), each of which is an attempt of a GA release. The final release candidate for each component will be the official GA release. There will be no breaking API changes between release candidate components and their GA releases.
• V1.0 general availability. The 1.0 releases will be subject to additional testing and productionization work.

Each OpenTelemetry component (components include each language-specific API + SDK, the OpenTelemetry collector, and projects like Java auto-instrumentation) will progress through these launch stages according to its own timeline, though we expect a first wave of components to publish release candidates at the same time.

The OpenTelemetry beta release occurred in March 2020. See the beta planning document and announcement for more details.

GA Requirements

We are planning to take a wave of OpenTelemetry components to GA in 2020. These components include the Java, JavaScript, Python, Go, Erlang, and .Net APIs and SDKs, along with the OpenTelemetry collector, and Java and Python auto-instrumentation agents. More components will reach GA according to their own dates.

We’ve set the following requirements for components to reach RC / GA:

Features

For a component to reach GA, it must include all metrics and tracing API and SDK spec <= 1.0 features. For APIs and SDKs this includes all features for traces, metrics, context propagation, and resource metadata. For the Collector this includes the OpenTelemetry proto format and system metrics.

Some important notes:

• Components can issue signal-specific release candidates. For example, an SDK can publish an RC that contains release candidate quality tracing functionality while metrics features are still declared to be beta quality.
• Logging functionality will be released to beta and GA at a later time, likely in 2021.

Breaking Changes

APIs and SDKs must not take any breaking changes between release candidates, the GA releases, and any subsequent releases that implement spec version < 2.0. This only applies to the parts of the API that are declared to be release candidate quality.

Exporters

Components must support the OpenTelemetry-native exporter, along with Jaeger, Prometheus, and Zipkin.

Documentation and Testing

See the planning doc for the full set of documentation and testing requirements. Test requirements are still in progress.

Tracking

Each SIG will need to track their progress towards the GA requirements, though every component SIG has dependencies on the specification SIG. This will be done through the following process:

1. The tracing and metrics spec SIGs will file issues for any specifications that must be completed for the GA release and tag them with release:required-for-ga. These will be tracked with an org-level GitHub project board.
2. Component SIGs will file issues for any features that need to be developed before a release candidate can be published and tag these issues with release:required-for-ga. These include pending GA specification features that haven’t been written yet and are tracked via point #1. These will be tracked with repo-specific GitHub project boards.

A combination of Morgan McLean, Ted Young, Carlos Cortez, and Andrew Hsu have been joining each SIG’s weekly meeting to check in on progress, unblock spec-related issues, and brief contributors about this plan.

Target Dates + Workplan

Tracing

The specification SIG is aiming to publish a release candidate of the tracing spec within the first week of September. While tracing functionality is already ~95% specified, there is still some additional work remaining related to context propagation that will be completed by this date. If there are still P1 GA tracing issues during the end of the first week of September, the technical committee and tracing spec approvers will make snap judgements to close any remaining issues, so please ensure that any remaining discussions occur well before this date.

As most tracing functionality is already implemented in the SDKs and the Collector, we expect that the features being specified now will be added to the SDKs and the Collector very shortly after this date, leading to tracing release candidates arriving in mid September. This will also unblock any remaining bridge work for OpenCensus and OpenTracing.

Metrics

The current focus of the GA workstream is to complete the tracing spec and publish tracing release candidates. Metrics spec, SDK, and Collector work is continuing in parallel with this, and we’ll perform a similar push once the first tracing spec RC is published.