Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

service.version being set by Composer #1320

Open
bobstrecansky opened this issue Jun 5, 2024 · 3 comments
Open

service.version being set by Composer #1320

bobstrecansky opened this issue Jun 5, 2024 · 3 comments
Labels
bite sized This is a small chunk of work (good for new or time limited contributors!) bug Something isn't working help wanted This issue is looking for someone to work on it

Comments

@bobstrecansky
Copy link
Collaborator

@julianocosta89 opened a slack thread to discuss seeing the service.version resource attribute set, even though it was not being set by default.

After getting more clarity in the #otel-community-demo channel, @puckpuck mentioned the following:

I did some sleuthing. This is set in the Composer detector here: https://github.com/open-telemetry/opentelemetry-php/blob/main/src/SDK/Resource/Detectors/Composer.php#L23-L26
Within Composer if you don't have a version set you will get the Default version which matches what we see in the otel-demo https://github.com/composer/composer/blob/main/src/Composer/Package/RootPackage.php#L22
I wonder if we should be using the version from Composer if it is set to the Default (unset)?


We should probably determine how we want to handle this service.version in the future. Other SIGs do not set this by default, so perhaps maybe we shouldn't have composer set this value if possible.

@bobstrecansky bobstrecansky added bug Something isn't working bite sized This is a small chunk of work (good for new or time limited contributors!) help wanted This issue is looking for someone to work on it labels Jun 5, 2024
@brettmc
Copy link
Collaborator

brettmc commented Jan 7, 2025

We have lots of detectors, and perhaps all isn't the best default? Detectors add overhead, so how about the default set is:

  • environment
  • sdk
  • sdk-provided

It's probably a BC-break behaviour-wise, so should go into 2.x?

@julianocosta89
Copy link
Member

@brettmc do we already have 2.x planned?

@brettmc
Copy link
Collaborator

brettmc commented Jan 7, 2025

do we already have 2.x planned?

Yeah, I've submitted #1463 to kick things off, and will discuss in an upcoming SIG. There are some spec additions which we can't implement in a non-breaking way, so it seems like a good time to start planning a major version bump and bundle in various deprecation-removals and breaking changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bite sized This is a small chunk of work (good for new or time limited contributors!) bug Something isn't working help wanted This issue is looking for someone to work on it
Projects
None yet
Development

No branches or pull requests

3 participants