TL;DR:
- All OTel distributions will be stable by default — experimental components require explicit opt-in
- Instrumentation libraries can stabilize independently of semantic conventions, so you get stable libraries faster
- New "epoch releases" provide tested, known-good component combinations for large-scale deployments
- Proposal is open for feedback from maintainers, end users, and integrators
The Context
Over the past year, the Governance Committee ran user interviews and surveys with organizations deploying OpenTelemetry at scale. A few patterns came up consistently:
Stability levels aren't always obvious. When you install an OTel distribution, some components might be experimental or alpha without clear markers. This makes it harder to evaluate what's production-ready.
Instrumentation libraries sometimes wait on semantic conventions. If a library's code is stable and safe to run, but the conventions it uses are still experimental, the library stays in pre-release. This delays access to stable instrumentation.
Coordinating versions across components takes effort. In environments with hundreds of services across multiple languages, aligning SDK versions, Collector components, and instrumentation libraries requires planning. Small version mismatches can introduce unexpected behavior.
The proposal targets these three areas with changes to how stability is communicated, how instrumentation releases work, and how tested component combinations are packaged.
3 Changes by OpenTelemetry Governance Committee
1. Stable By Default
The proposal standardizes how stability levels are communicated across all OTel components:
- Every component gets machine-readable metadata declaring its stability level
- Stable components need documentation, examples, and performance benchmarks — not just working code
- Stable distributions only enable stable components by default. Experimental features require explicit opt-in
This makes stability visible and consistent. If you're running a stable distribution, you know what you're getting without auditing individual components.
2. Decouple Instrumentation from Semantic Conventions
Semantic conventions evolve carefully because they need to work across different backends with varying cardinality constraints and capabilities. This careful evolution is necessary for consistency, but it creates a dependency for instrumentation maintainers.
The proposal changes how instrumentation stability works. If an instrumentation library's API is stable and safe to run in production, it can be marked stable — even if the conventions it outputs are still experimental. This lets users access stable instrumentation while conventions continue to mature.
The plan also includes making semantic conventions more federated. OpenTelemetry maintains core conventions. Third parties can publish their own extensions for specific libraries, frameworks, or tech stacks, reducing the coordination overhead with the core project.
3. Epoch Releases
Large-scale deployments often involve security reviews, staging environment testing, and coordination across multiple teams. The current release cadence, where components ship independently, makes it harder to identify tested combinations that work well together.
The proposal creates a Release SIG that publishes "epoch releases" — manifests pointing to tested, stable combinations of components. If you're managing OTel across many services, epoch releases provide a reference point for upgrades.
Individual components continue to version and release independently. Epoch releases add a tested configuration option for operators who need stability guarantees.
What This Means If You're Running OTel
If you’re deploying OTel across a large environment, these changes make rollouts easier. Stable-by-default distributions take the guesswork out of versioning. Decoupled instrumentation gives you stable libraries sooner. And epoch releases give platform teams a clean, tested baseline they can roll out across clusters without chasing breaking changes.
Where this really pays off is when your backend can keep up with the added detail and stability OTel is now shipping.
Last9 - a telemetry data platform is built specifically for this model.
Because we accept OTLP natively, the experience is the same whether you're sending stable signals or experimenting with new instrumentation. But the real value shows up once the data lands:
- High-cardinality attributes remain usable. Stable instrumentation surfaces more detail — customer IDs, deployment metadata, feature flags, rollout groups. Last9 keeps these attributes intact and queryable without clipping label sets or slowing queries.
- No constant tuning to keep the backend healthy. You don’t have to trim attributes, reduce volume, or adjust sampling just to stay within performance limits. The platform processes full-fidelity telemetry without forcing those trade-offs.
- Upgrades roll out without label-budget planning. As teams adopt newer instrumentation, attribute sets naturally grow. Last9’s architecture is built for that growth, so platform teams don’t have to coordinate cardinality caps across services.
- OTel upgrades stay predictable. Adding new versions of SDKs or the Collector won’t cause query failures or unexpected cost jumps. Our platform handles the additional attributes and metric streams as-is.
The new OTel stability work gives you stronger, more predictable telemetry — and Last9 is the observability platform that lets you use all of it without compromises.
Feedback and Next Steps
The Governance Committee is collecting feedback on the proposal. There's room for discussion on implementation details:
- Maintainers: How should stability requirements work without disrupting existing releases?
- End users: How are you managing upgrades now? What would make deployments easier?
- Integrators: What would make it simpler to consume and extend OpenTelemetry?
These changes show where OTel is focusing: stability, usability, and clear packaging. If you're running OTel in production or planning to, this is worth following.
References
- OpenTelemetry Blog: Stability Proposal Announcement
- GitHub: Discussion Thread
