[Feature]: Use #[deprecated] attributes on older interfaces vs. breaking removals

[clux]

Related Problems?

About every month or two there seems to be a dependency PR that gets stuck in every repo that uses otel because every release there's some major breaking change.

If you instead had kept the older fn interfaces for a few versions rather than blanket renaming it, we could tackle deprecations as warnings when we are actually at the source location, working on the application, with inline warnings that pop up in our editor. Something that is much easier than filtering 3 pages of compile errors from like 3 otel crates through a migration guide (if there is one). Particularly because you never know if you can truly tackle all the compile errors anyway because if you depend on something unreleased like tracing-opentelemetry, then your upgrade will likely fail anyway until they release.

Describe the solution you'd like:

Follow some kind of deprecation strategy, and remove the older interfaces at later times. This allows less breaking releases, which should also allow less need for dependencies to chase, and upgrade. I realise you plan on doing a 1.0, but that's still 15mo away.

Considered Alternatives

Being slightly annoyed at otel every release.

Additional Context

No response

[cijothomas]

Considered Alternatives
Being slightly annoyed at otel every release.

Yes, agree this is a pain. :(
At some point, we need to make breaking changes, and move towards stability. 0.28 has moved many components to Stable/RC, so the bar is now much higher for further breaking changes there. Logs, Metrics were expected to hit 1.0 stable soon, but moving that to mid of this year to let Traces also catch up. So 1.0 is ~6 months away, not 15 months now.

(For a lot of changes, we did the mark-as-deprecated, followed by actual removed in the next-release strategy. This was not fully followed all the time, especially for 0.28. Going forward we'll follow this wherever feasible.)

@open-telemetry/rust-maintainers Please share any additional points I may have missed.

Note: We expect to use tooling (https://github.com/open-telemetry/opentelemetry-rust/blob/main/.github/workflows/semver.yml) to make sure there won't be breaking changes post 1.0, which is still few months away, but not so far!