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

OTLP JSON exporter cannot be released #2804

Open
dyladan opened this issue Feb 24, 2022 · 8 comments
Open

OTLP JSON exporter cannot be released #2804

dyladan opened this issue Feb 24, 2022 · 8 comments

Comments

@dyladan
Copy link
Member

dyladan commented Feb 24, 2022

Currently, we are preparing to release the OTLP trace exporters as 1.x 🎉

Unfortunately, because OTLP JSON is experimental we cannot release the JSON exporter as 1.x and it must be held back to 0.x 😢

This is important because the transformations from our internal representation to the OTLP JSON representation are in the HTTP JSON exporter, and are depended on by the proto and gRPC exporters. If we hold back the JSON exporter but not the gRPC and proto exporters, we will end up in a situation where 1.x exporters depend on the 0.x exporter.

Possible resolutions:

  1. Hold back all OTLP exporters
  2. Prioritize feat(proto): add @opentelemetry/proto package #2691 or feat(proto): add @opentelemetry/otlp-transformer package with hand-rolled transformation #2746 and hold all exporters release until it is complete
  3. Hold back HTTP/JSON exporter and accept that the proto/gRPC exporters will depend on an experimental package until feat(proto): add @opentelemetry/proto package #2691 or feat(proto): add @opentelemetry/otlp-transformer package with hand-rolled transformation #2746 is implemented
@vmarchaud
Copy link
Member

I would be in favor of 2), i think it's better to have a "real" GA to avoid misunderstanding for users. (Btw i also think #2746 is preferable over #2691 for now, we could still switch back to codegen once it covers every issue)

@dyladan
Copy link
Member Author

dyladan commented Feb 25, 2022

One more advantage of #2746 is that it separates the transformation code from the code that encodes protobuf which makes it easier to pack a small bundle for the web. I'll try to get that PR updated today.

@icco
Copy link

icco commented Mar 9, 2022

2 or 3 would be preferred for us.

@github-actions
Copy link

github-actions bot commented May 9, 2022

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label May 9, 2022
@dyladan dyladan removed the stale label May 10, 2022
@dyladan
Copy link
Member Author

dyladan commented May 10, 2022

Not stale and still experimental

@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Jul 11, 2022
@github-actions
Copy link

github-actions bot commented Aug 1, 2022

This issue was closed because it has been stale for 14 days with no activity.

@github-actions github-actions bot closed this as completed Aug 1, 2022
@legendecas legendecas reopened this Aug 2, 2022
@dyladan
Copy link
Member Author

dyladan commented Aug 2, 2022

We can release the non-json exporters now that protobuf exporters are codegen and grpc exporters have their own base right?

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

No branches or pull requests

4 participants