Policy for instrumentation libraries supporting multiple major versions of library

[srikanthccv]

I think it is time we write down some clear policy for providing instrumentation support for third-party libraries that have multiple major (most probably incompatible) versions. It is not uncommon that users have different versions of same lib running in production systems within project/team/org. This is partly inspired by #935. I remember this was briefly discussed earlier and I would like bring it up again so that we can lay down guidelines for any future reference.

[rjduffner]

Second this.

Ya longer term support is an interesting problem. In #935 I dropped older versions but in #1000, I actually am trying to add an older (and slightly incompatible) version.

The reasons are selfish for sure but some policy would be helpful.

[lzchen]

@srikanthccv
Please bring this up in the next SIG meeting

[ocelotl]

@srikanthccv so, just to write a few things down:

Let's say we have an instrumentation for library X: opentelemetry-instrumentation-x.
Library X has several different and incompatible versions: 1, 2, and 3.

So, what you want is to define a policy regarding how will we write instrumentations for libraries that can work for different versions of the libraries?

For example, you want to define a policy that will say how should we write opentelemetry-instrumentation-x in order for opentelemetry-instrumentation-x to support library X in versions 1, 2 and 3?

[srikanthccv]

Yes. in one of the linked PRs, author is bumping the minimum supported version to > 2, < 4 from 1.x. Another one is proposing to lower the minimum supported version from 2.x to 1.x. This is arbitrary and motivated by their needs. A comprehensive policy to address this problem is needed. We may decide to not support the all the major versions 1, 2, 3 for library X. Or we may decide to support set of them where it possible to work around the incompatible changes with logical branches in just one instrumentation library. Or we may decide to release one instrumentation for each major version opentelemetry-instrumentation-x{1,2,3}. Or a combination of them?

[ocelotl]

Yes. in one of the linked PRs, author is bumping the minimum supported version to > 2, < 4 from 1.x. Another one is proposing to lower the minimum supported version from 2.x to 1.x. This is arbitrary and motivated by their needs. A comprehensive policy to address this problem is needed. We may decide to not support the all the major versions 1, 2, 3 for library X. Or we may decide to support set of them where it possible to work around the incompatible changes with logical branches in just one instrumentation library. Or we may decide to release one instrumentation for each major version opentelemetry-instrumentation-x{1,2,3}. Or a combination of them?

I wonder if we can keep as many branches in the opentelemetry-instrumentation-x repo as supported major versions of X exist. For example, let's say there X has 3 versions, 1, 2, 3, all of them being actively developed. We choose to support 1 and 3. So we have 2 branches in opentelemetry-instrumentation-x, branch 1 and branch 3. We keep making releases for versions 1 and 3 of X in the corresponding branches of the opentelemetry-instrumentation-x repo, where the releases have same major number of the corresponding version of X.

[srikanthccv]

Keeping aside the implementation part for now, I would like us to focus on the criteria for what to support. For example how did you arrive at supporting 1 and 3 for X?

[ocelotl]

It's an example, only. What I would want is a policy that allows us to support arbitrary versions of a library, not a policy that forces us to support all of them. I imagine a situation where for any reason we would like to skip support for a particular version can happen.

So, I think the policy should be support arbitrary versions of the different instrumentations on a case by case basis.

[rjduffner]

Note that #935 has been updated to not remove support for older versions of pymemcache.

[srikanthccv]

I am going to close this for now since @ocelotl made a strong case for doing it case by case.