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

Generate the v1.13 version of the semconv pacakge #3191

Closed
MrAlias opened this issue Sep 19, 2022 · 3 comments · Fixed by #3499
Closed

Generate the v1.13 version of the semconv pacakge #3191

MrAlias opened this issue Sep 19, 2022 · 3 comments · Fixed by #3499
Assignees

Comments

@MrAlias
Copy link
Contributor

MrAlias commented Sep 19, 2022

The v1.13 version of the specification has been released. A new v1.13 version of semconv needs to be generated for this.

@MrAlias
Copy link
Contributor Author

MrAlias commented Nov 22, 2022

Looking at the refactor necessary for the net and http functions, it smells like these functions should be removed from the semconv version packages.

They could be refactor and put into a separate dedicated package (i.e. go.opentelemetry.io/otel/semconv/httpconv). That way the semconv package could be updated and the dependency in the httpconv package separately updated.

Alternately, given these are only used in the net/http* instrumentation, they could be moved there. Not sure if they need to continue being exported.

@MrAlias
Copy link
Contributor Author

MrAlias commented Nov 23, 2022

They could be refactor and put into a separate dedicated package (i.e. go.opentelemetry.io/otel/semconv/httpconv). That way the semconv package could be updated and the dependency in the httpconv package separately updated.

The downside to this approach is that if there is again breaking changes to how semantic conventions need to be applied it could not be refactored without deprecations.

@MrAlias
Copy link
Contributor Author

MrAlias commented Nov 23, 2022

Alternately, given these are only used in the net/http* instrumentation, they could be moved there. Not sure if they need to continue being exported.

A quick search across all of GitHub show these functions are used in more than just the net/http instrumentation. Wherever they land they need to remain publically accessible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant