-
Notifications
You must be signed in to change notification settings - Fork 651
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
Provide versioned semantic conventions with sub-package/folder #2946
Comments
I think it would be better to separate our semantic conventions code in a different repo so that we have an
|
Something else:
In summary, using actual released packages with their corresponding versions to protects the integrity of those versions because it is guaranteed that the code in a specific version of a package will never change. Using directories named after versions is a fragile approach. |
I like this idea of releasing
I'm not sure if this is a great situation, as it may mean that with multiple semconvs being used applications will produce telemetry differently, this should be ok so long as schema URLs are set correctly. I do struggle with the idea of having a continuously increasing package size. If this is the route the community wants to take, I'd recommend placing some kind of limit for how many versions back would be supported. There is precedent for including multiple versions within a single package, the kubernetes client package does this (https://github.com/kubernetes-client/python/tree/master/kubernetes/client/api). |
I worry this sets an incorrect expectation that other SDK packages also follow and keep in sync with the spec release. Does any other SIG do this today?
This assumes that a new semantic version didn't delete anything which is not the case now. Take a look at the recent release, there are some attributes removed from the HTTP attributes which means the user might have to update the application code if they want to use the new version. In a sense, we are also the users (contrib repo), if we want to use the 1.13.0 version we must update the instrumentation library code.
No handmade changes will be done to this package. It's all generated from sem conv yaml files.
This is a valid concern and I think the idea of limiting the number of versions is a good suggestion. |
The application code may need or not to be updated if another version of the semantic conventions are used but that is not the point here. The point here is that when using version-named directories a dependency version is being specified outside the requirements file and into the application code.
That does not matter, with the version-named directories approach that generated code can be modified by any commit.
Limiting the number of versions is a solution that introduces another problem, an user will not be able to use an old version after it is deleted. Having a separate package for the semantic conventions does not have the problem of code growing and also it does not have the problem of having to delete old versions. |
Isn't the idea behind |
@ocelotl @srikanthccv
makes sense. I can totally see users setting up their application once and never updating the semantic conventions again as soon as it fits their business use case. If these conventions get outdated/obsolete this could be troublesome. However, as to @codeboten 's point,
maybe the above problem isn't as bad as we think realistically for users? Maybe the desire to have a stamped "stable" on our product is more appealing to users than it is to update their code once in a blue moon? As long as we are transparent with our users and give them ample time/warning to upgrade (before deleting older versions of semconv), is that so bad? |
No, I am suggesting to have our |
Isn't this what we already do today? How would users be able to use semantic version X without having to update their instrumentation version as well? Maybe I'm not fully understanding. Feel free to add this topic to Thursday's agenda. |
Sure, I will 👍 |
In the SIG we discussed that the problem with the approach I suggest is that we expect that it will be frequent that an instrumentation will pin its dependency to a version of semantic conventions and another one to another version so that the user will have a problem when trying to install both in the same virtual environment (I specifically mention frequent here because the same can happen to other packages like There is another solution that has all the advantages of the approach I suggest without this problem, and that is to make a new package named Another advantage of this approach is that if it happens that the semantic conventions in the spec someday become a stable thing that follows semantic versioning we can just start having the release of The disadvantage of this approach is that is horrible. But it works. 🤷 WDYT @srikanthccv @lzchen @aabmass ? |
👋 New here, so feel free to ignore this... there is lots of context I don't have! FWIW, I have used the "subpackage-versioning" strategy from foo.v1_2_3 import bar within private packages to cushion against version conflicts while providing backward compatibility. It isn't the strangest thing I've seen, although I agree it also isn't the most straight-forward. All told, the I think creating an entire new package for every version has a few downsides:
|
So is your new proposal aligned with my question from before? |
This is normal, everytime an user wants to update a library the will add a change in their
This is true.
This is true.
This is true as well. I am proposing a horrible solution, indeed. |
That's right, it is. |
@codeboten I agree that would be nice. I see two way to do this without breaking semantic versioning
Also re package size, I did a quick test by copying semantic conventions 200 times in src tree to get some rough estimates:
This is similar to |
This could be an alternate solution open-telemetry/semantic-conventions#214 to avoid backward compatibility issues when fields are removed. |
Do we still want to explore this now that we have agreed that we will be carrying out the migration plan for OT sem conv? https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md |
To refocus this conversation, the goal of this issue is to mark opentelemetry-semantic-conventions PyPI package as stable with no expectation of every having a major version bump. The benefits are:
|
The idea is to create a new folder for each version of semantic conventions release and instrumentation packages or end users can choose which one to use.
The folder structure will look like following
It is convenient to use this because we don't necessarily need to update the instrumentation every time there is a spec release. This will enable us to mark the package as stable since there will always be a backward compatible sub-package but the downside is it can grow big over time. The current size of the package seems to be around 26kb https://pypi.org/project/opentelemetry-semantic-conventions/#files. Original inspiration from go SKD https://github.com/open-telemetry/opentelemetry-go/tree/main/semconv
The text was updated successfully, but these errors were encountered: