One OpenTelemetry-Go tag moves four modules and retires old Go versions

There is no binary to install, only a module path and pinned deps

The unit of distribution is a Go module rather than a program. The root module is go.opentelemetry.io/otel, declared with a go 1.26.0 directive, and its dependencies are fixed in go.mod:

module go.opentelemetry.io/otel

go 1.26.0

require (
	github.com/cespare/xxhash/v2 v2.3.0
	github.com/go-logr/logr v1.4.4
	github.com/go-logr/stdr v1.2.2
	github.com/google/go-cmp v0.7.0
	github.com/stretchr/testify v1.12.1
	go.opentelemetry.io/auto/sdk v1.2.1
	go.opentelemetry.io/otel/log v1.47.0
	go.opentelemetry.io/otel/metric v1.47.0
	go.opentelemetry.io/otel/trace v1.47.0
)

Three of those lines are the same repository at different paths: log, metric, and trace are separate modules carrying their own version numbers. Reading the block tells you what an application actually pulls in, which is a logging interface at go-logr/logr, a hash function, a diff library and a test framework, plus the three signal modules. There is no install script and no service to start.

One release tag carries four version numbers

The v1.47.0 release is published as v1.47.0/v0.69.0/v0.23.0/v0.1.0, so a single tag moves four modules spanning v1 and v0 version lines. The previous pair shows the same shape: v1.46.0 came with v0.68.0, v0.22.0, and v0.0.19, and v1.47.0-rc.1 sat between them on August 28, 2026. The mechanism is visible in the root go.mod, which redirects the three signal modules to local directories during development:

replace go.opentelemetry.io/otel/trace => ./trace

replace go.opentelemetry.io/otel/metric => ./metric

replace go.opentelemetry.io/otel/log => ./log

The release tooling behind that lives in internal/tools, and the Makefile builds multimod and crosslink from go.opentelemetry.io/build-tools into a .tools directory. The consequence for a consumer is that pinning one module path does not pin the others, so a build that only names go.opentelemetry.io/otel can still resolve a different log or trace version.

A Go release is supported until two newer ones exist

The compatibility rule is stated as a policy rather than a version list: each major Go release is supported until there are two newer major releases, illustrated by Go 1.5 being supported until the Go 1.7 release and Go 1.6 until Go 1.8. Retirement runs in two steps. First, a minor release of opentelemetry-go is made to add support for the new supported Go release. Then the following minor release removes compatibility testing for the oldest, now archived upstream, version, and from that point releases may include features only supported by the current versions.

Windows on arm64 has no row in the supported matrix

The environment table is explicit about what is tested:

| OS       | Go Version | Architecture |
|----------|------------|--------------|
| Ubuntu   | 1.27       | amd64        |
| Ubuntu   | 1.26       | amd64        |
| Ubuntu   | 1.27       | 386          |
| Ubuntu   | 1.26       | 386          |
| Ubuntu   | 1.27       | arm64        |
| Ubuntu   | 1.26       | arm64        |
| macOS    | 1.27       | amd64        |
| macOS    | 1.26       | amd64        |
| macOS    | 1.27       | arm64        |
| macOS    | 1.26       | arm64        |
| Windows  | 1.27       | amd64        |
| Windows  | 1.26       | amd64        |
| Windows  | 1.27       | 386          |
| Windows  | 1.26       | 386          |

Apple Silicon macOS is covered on arm64, and Windows is covered on amd64 and 386, but there is no Windows arm64 entry. The project also states that while it should work for other systems, no compatibility guarantees are made for those systems currently. So a build on Windows on arm64 is outside the tested set in the same way as FreeBSD or a 32-bit ARM board would be.

The Prometheus exporter here carries metrics and nothing else

The officially supported exporters all live in the exporters directory, and their coverage is uneven:

| Exporter                              | Logs | Metrics | Traces |
|---------------------------------------|:----:|:-------:|:------:|
| [OTLP](./exporters/otlp/)             |  ✓   |    ✓    |   ✓    |
| [Prometheus](./exporters/prometheus/) |      |    ✓    |        |
| [stdout](./exporters/stdout/)         |  ✓   |    ✓    |   ✓    |
| [Zipkin](./exporters/zipkin/)         |      |         |   ✓    |

Only two of the four carry all three signals, OTLP and stdout. The Prometheus exporter is marked for metrics alone, with no logs and no traces column filled, and Zipkin is the mirror image with traces alone. That asymmetry is the concrete answer to whether the two projects are interchangeable: here Prometheus appears as one exporter among four, and, like Zipkin, it carries no logs.

Instrumentation for frameworks lives in another repository

Adopting the library is described as two steps: instrument your application, then configure an exporter. The easy path for the first step is an instrumentation library for your code, drawn from the officially supported list. The project does not host that list itself. It points to a separate instrumentation directory in opentelemetry-go-contrib, and the practical examples it recommends are in that repository's examples directory too. Only when you need to extend what an instrumentation library already collects, or want to build your own instrumentation directly, do you reach for the go.opentelemetry.io/otel package itself. The practical consequence is that instrumenting a common web framework or HTTP client means adding a dependency outside this repository.

Nine checks run before a default build, and one linter is pinned

The Makefile sets its default goal to precommit, not to build:

.DEFAULT_GOAL := precommit

.PHONY: precommit ci
precommit: generate toolchain-check license-check misspell go-mod-tidy golangci-lint-fix verify-readmes verify-mods test-default
ci: generate toolchain-check license-check lint verify-readmes verify-mods build test-default check-clean-work-tree test-coverage

So a plain make invocation runs generate, a toolchain check, a license check, misspell, go mod tidy, golangci-lint with fix enabled, a README verifier, a module verifier, and the default tests. The ci target swaps the fixing linter for a checking one and adds build, a clean work tree check, and coverage. The Makefile sets TIMEOUT = 60, and the Go version is read out of go.mod rather than pinned separately. Auxiliary tools, including semconvkit and verifyreadmes, are compiled from internal/tools, while the Python side is a single pinned dependency:

codespell==2.4.3

All three signals are marked stable, and the API is separated by directory

The status table reports Traces Stable, Metrics Stable, and Logs Stable, with progress tracked on project boards and milestones and the stability guarantees written down in VERSIONING.md. The repository root mirrors that split into directories: attribute/ and baggage/ for context, propagation/ for crossing process boundaries, trace/, metric/, and log/ for the three signals, sdk/ for the implementations, plus bridge/, codes/, exporters/, internal/, and semconv/ for the semantic conventions. Alongside them sit single files that define the API surface, among them trace.go, metric.go, log.go, propagation.go, error_handler.go, handler.go, version.go, and versions.yaml. An application that only wants to produce signals can depend on the API packages and leave the sdk/ tree alone until it wants to run them.

Editorial conclusion

OpenTelemetry-Go suits a team that wants vendor-neutral instrumentation with all three signals marked stable and a written support window. It does not suit a team expecting framework wiring here, since integrations live in a separate contrib repository, and it offers no guarantee for Windows on arm64. Before adopting, check which exporter your platform accepts, then read VERSIONING.md for the stability guarantees you would be relying on.

Frequently asked questions

Official sources

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