OpenTelemetry .NET: three releases of one version on the same morning

The repository contains only what the specification defines

The repository structure section states the scope rule in one sentence: this repository includes only what is defined in the OpenTelemetry specification, and it ships as separate packages through the package registry. Everything the specification does not define lives elsewhere. Instrumentation libraries, additional exporters, resource detectors and extensions are in a separate contributions repository. So the boundary is a document written by a different group, and it is enforced by what is absent rather than by a policy statement. The cost is that a .NET team with a common need will often need two dependencies and two version streams, one from each repository. The benefit is that anything in here is portable in the way the specification intends, and the page points at a compliance matrix maintained in the specification repository so you can check coverage against the spec rather than against a release note.

Three releases of one version, in one morning

The three most recent tags are all the same version, on the same day, and they come from three different tag families. There is a release candidate, a stable patch, and a beta on a separate package family whose name begins with a word meaning unstable. The timestamps place the candidate first in the morning, the stable release a little over an hour later, and the unstable beta a few hours after that. The naming is the more important signal: this project does not version one library, it versions packages individually, so a tag such as the core package at one point one nine one means nothing on its own without knowing which package and which family. If you consume several of these packages, your dependency resolution is across many version lines rather than one, and the page has a dedicated versioning document explaining pre-release marking to make sense of it.

Stable across three signals, with breaking changes still permitted

The project status section opens with a claim that is easy to read and easy to over-read: stable across all three signals, named as logs, metrics and traces. Immediately under it sits a caution. Certain components, marked as pre-release, are still work in progress and can undergo breaking changes before their stable release, and the reader is told to check each component's own readme for its current state. So stability is a property of a package, not of the repository, and the repository's headline is a summary that the caution then qualifies. For an adopter this means the version you write in your manifest is not the version you can rely on. The page is honest about it, which is more than most, but the practical consequence is that the pre-release marker on each package is the thing to check rather than the project status heading.

Twelve documents that differ only by their folder

The getting started section is three identical shapes. For each of logs, metrics and traces it recommends the same two five minute guides, one for a web framework application and one for a console application, then a general document with background and best practices, then a document on customising the software development kit for that signal. Twelve links in three groups of four, and every one of them differs from its sibling only in the folder in the path. That is what a specification-driven project looks like when the three signals have the same shape, and it is a reasonable way to write it. The one blemish is that the folder names are not consistent: two of them are plural and the third is singular. A repository with a markdown lint configuration and a spelling configuration at its root did not catch it, which tells you the linting covers prose rather than paths.

Supported means whatever the runtime supports, minus one version

The supported versions statement is deliberately relative rather than absolute. Packages generally support all the officially supported versions of the modern runtime and of the older Windows based one, with the exception of version three point five of that older runtime, which is named explicitly. Anything that does not follow is noted in the individual package readme. So there is no version list to memorise and no compatibility table to check: the support window is whatever the runtime vendor currently supports, and this library inherits it. That is a good default for a library that has to run wherever the application runs. It also means the library's own support commitment changes without a release, and that a package which deviates tells you so only in its own readme rather than in any central table.

Compliance with the specification is answered in another repository

There is a paragraph whose entire job is to point somewhere else. To understand which portions of the specification have been implemented here, the page sends you to a compliance matrix maintained in the specification repository. So the authoritative answer to the only question that matters for a cross-vendor portability claim, namely whether a given part of the specification works in this language, is maintained by the specification authors rather than by this implementation. That is the right ownership for the information and it does mean the two repositories have to be read together. The same pattern shows up in the scope split: the specification decides what belongs here, the compliance matrix records whether it landed, and this page only summarises the result.

Two Prometheus exporters and one exporter marked deprecated

The exporter list is six entries and two observations come out of it. There are two Prometheus exporters, one built for the web framework integration and one built around a plain HTTP listener, so the choice is not which protocol to use but which host to run the metrics endpoint in. And the Zipkin entry is the only one in the list with a deprecation marker, so a project that was on a distributed tracing model and is now on the vendor-neutral protocol has a migration note on the page rather than only in a changelog. The rest of the list covers console output, an in-memory target, and the vendor-neutral protocol exporter, which is the one most teams will actually use. Additional exporters are not here; they are in the contributions repository named earlier.

A PowerShell benchmark script and a dead man's switch config

Two files at the root describe how this project looks after a decade of governance. There is a configuration file for a dead man's switch service, which is a hosted monitor that expects a scheduled job to check in and emails you when the check-in stops, so this repository has a watchdog telling a third party when its own automation goes quiet. And there is a single benchmark script, written in PowerShell, which is the only performance entry point in a project whose contributors run Linux and macOS containers. Alongside them sit two solution files using the newer solution format, one for the main set and one for the extended set, a file pinning the software development kit version for every contributor, a review document, and central package and build property files. It is a repository with a lot of process, which suits a project this size.

Editorial conclusion

This repository suits a .NET team that wants telemetry collection defined by a specification rather than by a vendor, and that will accept per-package versions rather than one library version. Four things to check first. Stability is per component, not per repository: the page calls the three signals stable and then says components can still take breaking changes before they reach stable release. Whether this repository implements a given part of the specification is answered in another repository's compliance matrix, not here. The two Prometheus exporters and the deprecated Zipkin exporter mean you may need more than one backend package. And the supported-runtime statement tracks the runtime's own support policy with a single named exception, so your support window is the runtime's, not the library's.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-telemetry/opentelemetry-dotnet on GitHub
3. Project website
4. README
5. Releases