# OpenTelemetry Go Logs API and SDK enter release candidate > The Go Logs API and SDK reached release-candidate status for direct application use and logging bridges, while exporters and logtest remain experimental. Canonical URL: https://www.devobs.io/news/news-opentelemetry-go-logs-release-candidate/ By: Claire Dubois Published: 2026-09-06T11:58:54.649Z Updated: 2026-09-06T11:58:54.649Z Event date: 2026-08-31 Section: Developer tools OpenTelemetry announced release-candidate status for its Go Logs API and SDK on August 31. The [project update](https://opentelemetry.io/blog/2026/go-logs-api-sdk-rc/) asks developers to exercise the interfaces in real applications and integrations before the stable release. ## The API now addresses direct use and bridges The project originally focused the API on logging bridges, but broadened it so applications can use it directly as well. That gives reviewers two distinct paths to test: emitting records through the OpenTelemetry API and adapting an existing Go logging library through a bridge. For either path, send structured records with severity, timestamp, attributes, trace context, and stable resource identity through the intended SDK pipeline. Compare the exported record with the original. A bridge test should also verify that the application does not keep a second exporter active, because duplicate delivery can inflate storage and alert counts while both pipelines appear healthy. The release also moves global accessors into the root package. It adds Logger, GetLoggerProvider, and SetLoggerProvider, while the older log/global package is deprecated. Libraries adopting the candidate should compile and test this transition rather than postpone it until stable. ## The release-candidate boundary is narrow The candidate designation covers the final API and SDK modules, otel/log and otel/sdk/log. Exporters and the logtest testing package remain experimental. A team should therefore avoid treating the entire Go logs stack as release-candidate quality simply because the core modules reached that stage. Pin module versions during evaluation and record which exporter and bridge versions were used. Testing both direct calls and existing logging integrations now gives maintainers useful compatibility evidence while keeping experimental components clearly separated from the candidate stability promise. ## Source references -