Feedback on Stability and Release Practices Proposal

[austinlparker]

This is a space to discuss our stability proposals.

To summarize and recap the blog, these are our goals that should be addressed:

• Ensure that all OpenTelemetry distributions are ‘stable by default’ and provide standardized mechanisms for users to opt-in to experimental or unstable features.
• Have a single, clear, and consistent set of criteria for stability that includes documentation, performance testing, benchmarks, etc.
• Make it easier for instrumentation libraries to stabilize and encourage federation of semantic conventions.
• Introduce ’epoch releases’ that are easier for end-user organizations to consume.

We plan to introduce these changes via OTEPs in the specification, but would like to use this space to collect feedback from the community, end-users, maintainers, and others about the goals and objectives, as well as how they're achieved.

[jkowall]

There is a lot of good stuff in here @austinlparker thanks for putting it together. How do you plan to enforce this with so many distributions out there, is the objective to have a certification for distributions?

I assume these crtiera would allow it to be certified in some way?

Have you considered LTS versus "epoch" releases? In Kubernetes they always avoided this as it creates more work for the maintiners to patch/merge/build multiple versions. They expected the vendors to implement this which most of them have done and handle themselves.

[austinlparker]

These proposals are only focused on the things we can control; e.g., java agent, collector, etc. I can see a future state where there's ways for other people to release distributions that align with the upstream strategy though.

To your LTS point -- we, effectively, already have LTS releases (see https://github.com/open-telemetry/opentelemetry-specification/blob/d5cfbdf78edd7a81a14397eeea5a93b586c46326/oteps/0232-maturity-of-otel.md and https://github.com/open-telemetry/opentelemetry-specification/blob/d5cfbdf78edd7a81a14397eeea5a93b586c46326/oteps/0143-versioning-and-stability.md), or at least something close to it. The problem is that each individual sig, effectively, gets to pick how they release (and in many cases those sigs are mixing stable and unstable features/code together in ways that aren't easy for end users to understand).

The idea with epochs is that we can provide a stable, documented, and tested integration point across all SIGs in order for end users to consume updates in a more structured way.