Should all packages have the same version?

[reyang]

Currently we're taking the easy approach - all the packages have the same version.

We were using this approach initially in OpenCensus Python, until we hit beta - there were new packages being added which are not ready (based on beta quality) so we ended up allowing each package to have its independent version. And this is what we carried over to OpenTelemetry Python.

Some of the obvious pros/cons to consider:

1. Having independent version gives us extra work.
2. Not having independent version means if someone added a cool component (e.g. logging), it will immediately inherit whatever version used across the project (e.g. it could be GA 1.0).

[pcwiese]

In my opinion, true semantic versioning is totally lost when everything shares the same package version. From a consumer perspective, it is better to be able to pull in targeted fixes rather than be forced to upgrade all packages. But doing this is hard and introduces developer friction for sure.

[beef3333]

I have had good success using this to help automate generating versions per package, https://github.com/dotnet/Nerdbank.GitVersioning

[alanwest]

I think it's nearing time for us to come back to this discussion.

Up to now, we have maintained a distinction between core and non-core packages.

Core packages

Per our current versioning guidelines, we have indicated that core packages will always have the same version.

Core components refer to the set of components which are required as per the spec. This includes API, SDK, and exporters which are required by the specification. These exporters are OTLP, Jaeger, Zipkin, Console and InMemory.

The core components are always versioned and released together. For example, if Zipkin exporter has a bug fix and is released as 1.0.1, then all other core components are also released as 1.0.1, even if there is no code change in other components.

Option 1: Maintain the current versioning policy long-term

There are a number of packages which should be considered core but do not yet have a stable release. I believe our process should be that as these packages reach stability, we should bump their versions to whatever the latest stable version is for the rest of the core packages. This includes the following:

• Future core packages
  • Prometheus exporter
  • Prometheus framework dependent bits - e.g. Prometheus.Exporter.AspNetCore (or whatever we end up calling it)
  • Jaeger propagator (Support for Jaeger Propagator #1881)
  • OpenTracing shim
  • ZPages exporter
  • Any other future component that becomes specified

For comparison, this option roughly maps to what the Java community is doing. The recommended method of consuming the core Java packages is to use their BOM (bill of materials - kinda like a meta-package) https://github.com/open-telemetry/opentelemetry-java#published-releases.

Option 2: Allow for independent versioning of core packages

This option would enable us to remain more true to semver as previously mentioned #917 (comment).

Aside from the benefits of what semver communicates to end users, this option would also enable us to do things like separately bumping the major version of just the OTLP exporter as proposed in this discussion. I think adopting option 1 should preclude us from doing this.

Non-core packages

Today, non-core packages include all our instrumentation packages and the OpenTelemetry.Extensions.Hosting package.

Option 1: Do away with core/non-core distinction by considering everything a core package

If the package is hosted within the opentelemetry-dotnet repository then we consider it "core".

Option 2: Do away with core/non-core distinction by moving non-core packages out of this repository

Non-core packages would move to opentelemetry-dotnet-contrib (or maybe even opentelemetry-dotnet-instrumentation).

---

My current preference is to adopt Option 1 in both cases. That is, all packages are considered "core" and all packages are always versioned together. Personally, I appreciate that the most common instrumentations reside within the opentelemetry-dotnet project.

Given that OpenTelemetry will remain an emerging technology for some time now, I think we should prioritize the simplicity of maintenance.

If we take this approach, we may need to reassess this decision in the future. I can imagine scenarios where it could cause friction, but I do not feel that we've reached that point yet.

[martinjt]

I believe we've established the approach for this now? do we have a reference to the ultimate decision for this @alanwest?

[Kielek]

Closing. It was improved some time ago in #5531