service.version being set by Composer

[bobstrecansky]

@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.

[brettmc]

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]

@brettmc do we already have 2.x planned?

[brettmc]

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.