System.Diagnostic.DiagnosticSource nuget overrides version provided by .NET about opentelemetry-dotnet HOT 7 CLOSED

DiagnosticSource latest version is needed in OTel, and that is by-design.
https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/Directory.Packages.props#L46-L55

from opentelemetry-dotnet.

DiagnosticSource latest version is needed in OTel, and that is by-design. https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/Directory.Packages.props#L46-L55

Could you explain the design decision here. This makes working with package when you don't have the latest version of the api very difficult.
It also means that bumping between versions is much harder.

Is there a policy around this? It seems like a breaking change to the API and should at a minimum rev the version of OpenTelemetry. Otherwise this is a poison pill to anyone who has compatibility issues.

There seem to be multiple issues in which users are dismissed without a policy or understanding just that "it is the way":
#3448
#4047
#2824

It seems like a good policy would be to at a minimum maintain compatibility with the latest LTS which is .NET 6
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

from opentelemetry-dotnet.

The design decision is already explained here:
https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/Directory.Packages.props#L46-L55

OTel needs latest version of DS. Its independent on the actual .NET version the app is running. DS is shipped as out-of-band.

Also adding to docs as well. Some are added: https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics#package-version, more coming.

It seems like a breaking change to the API
Sorry, I don't follow this.. What is the breaking change here?

from opentelemetry-dotnet.

The design decision is already explained here:

https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/Directory.Packages.props#L46-L55

It seems like a breaking change to the API

Sorry, I don't follow this.. What is the breaking change here?

This would be the type of breaking change mentioned.
https://learn.microsoft.com/en-my/dotnet/standard/library-guidance/breaking-changes#behavior-breaking-change

Adding features and improving bad behaviors is a good thing, but without care it can make it very hard for existing users to upgrade. One approach to helping developers deal with behavior breaking changes is to hide them behind settings. Settings let developers update to the latest version of your library while at the same time choosing to opt in or opt out of breaking changes. This strategy lets developers stay up to date while letting their consuming code adapt over time.

Currently you're forcing an update to a library which is a breaking change 6->7->8 of a transitive dependency. That dependency is used for other things and doing this forces code changes across a large code base before being able to take advantage of incremental improvements in your library.

from opentelemetry-dotnet.

@hdost Its not clear what is the breaking change you are referring to?

1. Can you give a concrete example?
2. And what is your proposal instead of depending on latest version of DS?

from opentelemetry-dotnet.

I noticed that OTEL also forces Microsoft.Extensions.* 8.0.0+. We don't plan to use these nugets before migrating to .NET 8. Is that a requirement for OTEL to work? I would expect these nugets to match the target framework version.

from opentelemetry-dotnet.

@cijothomas i think what may be a bit more confidence building is actual policies around how these policies are defined

Because as @verdie-g mentioned above there's more than just a single library at issue.

3. Since version 3.1.0, the .NET runtime team is holding a high bar for backward compatibility on these packages even during major version bumps, so compatibility is not a concern here.

This is a statement in this repo, but there's no link to a public commitment on these. Our hesitancy towards this is that we just spent a significant amount of effort to upgrade to past 3.1 and it was painful to say the least. We're dealing with thousands of modules across hundreds of repositories. So you'll have to excuse us for not taking the word of a comment in a properties file.

Is there some sort of policy for public view? Most google searches lead me to nothing of the sort.

I have seen this similar "high bar language" but aside from a github comment or a line in a config file I'm not seeing anything.

EDIT: I have since found dotnet/docs#31974 but it's still unresolved.

from opentelemetry-dotnet.