Rename logs_level_enabled flag to spec_unstable_logs_enabled

[lalitb]

Changes

The flag was added when this feature was not there in specs, so named as logs_level_enabled. However, now the feature is there in specs under Dev state, so renamed it to spec_unstable_logs_enabled.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.4%. Comparing base (0cc2cd5) to head (d7000f5).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2291   +/-   ##
=====================================
  Coverage   79.4%   79.4%           
=====================================
  Files        122     122           
  Lines      20783   20783           
=====================================
+ Hits       16504   16506    +2     
+ Misses      4279    4277    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cijothomas]

https://github.com/open-telemetry/opentelemetry-rust/pull/2291/files#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055R156 Based on the wording here, the experimental spec based things should be feature flagged under otel_unstable ? Do we want to follow that approach or modify it?

[lalitb]

Yes, I thought using otel_unstable. But I think not good to use single feature flag for all the features. Will revisit the wording in separate PR.

[lalitb]

How about:

experimental_<flag-name>:

• Use for features that are NOT in any specification
• These are purely experimental/exploratory features
• When the feature's implementation becomes stable, rename to <flag-name>

unstable_<flag-name>:

• Use for features that ARE in specifications but either:
  • The spec itself is still experimental, or
  • The spec is stable but our implementation is incomplete
• Remove this feature flag entirely once the feature is fully implemented and stable

[lalitb]

renamed to unstable_logs_level_enabled based on above comment.

[cijothomas]

the name logs_level_enabled is not very clear. enabled() takes more than level, so why specially mention level?
maybe unstable_logs_enabled is good enough.?

Also, I am wondering if we need separate flags for each feature or a single flag for all unstable spec ones? The previous discussion is here #1410 (comment)

[lalitb]

maybe unstable_logs_enabled is good enough.?

Agree unstable_logs_enabled seems better

Also, I am wondering if we need separate flags for each feature or a single flag for all unstable spec ones?

Yes, the agreement in above link was to have otel_unstable as a single feature flag to enable/disable all features for which

• specs is still experimental,
• implementation is stable as per the current specs (i.e, won't crash/panic, no perf issues)
• can have breaking changes if the specs changes.

which means that it would be safe to enable/disable such features together without affecting the other existing performance. logs_level_enabled does fall in this category.

[lalitb]

Thinking more, I feel this brings better clarity, with different flags for each feature. I can update the CONTRIBUTION.md guide is we agree.

[cijothomas]

Thanks!