-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Define backwards compatibility criteria #239
Comments
Please also make sure that you tag the relevant docker images as well whenever there is a breaking change :) |
How are we going to version REST API? Using URI or header? Currently we have |
while we are on 0.x releases I'd stay away from /v1/, but in the future - yes.
How do you mean? We (internally) are using HTTP endpoint with jaeger.thrift to submit spans from outside of out data centers (from cloud based blackbox monitoring). |
To zipkin endpoint. |
I think we should decommission |
@yurishkuro agree |
I think it would be better to have the version as part of the content type and do proper content negotiation instead of sub resource scoping. |
@omeid can you point to prior art? |
@yurishkuro was this completed for v1? Now that the model we use for gRPC is stable, it would be a good time to document what are the backwards compatibility expectations. |
still waiting for Query service gRPC API |
This can now be revisited |
Once we release 1.0 version, there will be stronger expectations of backwards compatibility. We need to enumerate what they are and have some way of validating them.
The text was updated successfully, but these errors were encountered: