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

add alpha/beta deprecation OTEP #34

Closed

Conversation

lizthegrey
Copy link
Member

@lizthegrey lizthegrey commented Aug 28, 2019

We need to be able to deprecate OpenTelemetry beta SDKs, while not breaking beta APIs too often.

@lizthegrey
Copy link
Member Author

(unresolved question: what about the exporter-SDK API? how willing should we be to break that?)

@tedsuo
Copy link
Contributor

tedsuo commented Sep 1, 2019

I really like the idea of timed releases, as a way to bundle up changes into a single release.

My concern for backwards compatibility support for the API during the beta is that it can be very tricky to accomplish. In my experience from OpenTracing, when we made important changes to handle new edge cases and requirements, those changes almost by definition did not play well with the existing API. So while we managed to provide backwards compatibility, it was very constraining and slowed the work down significantly, and meant that in some cases we could not pursue an idea which we thought was better.

I'm thinking of core modeling issues here btw, like span and scope management, and not simpler issues like "should we expose tracestate or not?" Since this project is a reboot, I'm hoping we don't have many of these types of issues! But, given that we have yet to exercise any of these APIs vigorously, I'm concerned that different SIGs may still have some surprises awaiting them.

I suppose this is my question: When deprecation support is straightforwards, I think we should do it during the beta. But if we discover a bigger or more fundamental issue in an API, I would want to be able to change things and make a hard break. How do you suggest we handle those situations?

Post-beta, strict backwards compatibility will be a critical feature for this project (it was for OpenTracing as well). After a release candidate becomes v1.0, we will need to have full API support for existing instrumentation on the order of years - basically forever. But that's a separate issue! :)

@lizthegrey lizthegrey changed the title add beta deprecation OTEP add alpha/beta deprecation OTEP Sep 11, 2019
@lizthegrey
Copy link
Member Author

Post-beta, strict backwards compatibility will be a critical feature for this project (it was for OpenTracing as well). After a release candidate becomes v1.0, we will need to have full API support for existing instrumentation on the order of years - basically forever. But that's a separate issue! :)

Please take a look; have clarified that during alpha, we should feel free to make breaking changes, during beta we should be careful about but not tie our hands, and post-beta we need to maintain a seamless path.

@lizthegrey lizthegrey closed this Dec 17, 2019
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 this pull request may close these issues.

None yet

2 participants