-
Notifications
You must be signed in to change notification settings - Fork 257
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
metrics: Meta issue about Data Model Stability Guarantees #275
Comments
I also discovered (#269) PR which changes the name of Summary. This is something that would techncially break compatibility. Likely if we want to follow the above proposal we should consider reverting it before Step 2. Or more than likely re-add it and have the plain summary. The |
cc: @jmacd , @bogdandrutu |
@hdost Acknowledging your point, we have to be careful how we describe these changes before the next release. Also we did not write a Changelog entry in #270, which led me back to this issue because I'm not sure how to classify the change. It's partly breaking (remove IntHistogram) and partly non-breaking (just a rename) -- because we have not declared JSON stability. |
👍🏼 I do remember that JSON stability wasn't set, but I wasn't sure how things affect on the Protobuf side. |
I believe this issue is now outdated. Metrics are declared Stable. Closing. Please open a new issue if you believe something else is needed. |
There are a couple of issues which are looking at breaking changes.
According to the README.md right now. Metrics is considered Beta. However, as part of the 0.5.0 release there is a mention:
I believe from what I understand that it should still be considered Beta given it's state. And the fact that only as of 0.7.0 was it even marked as Beta
Related Change Propositions:
#257
#264
#272
As mentioned in #264 (comment) we should try to make the transition smooth.
Taking a cursory look at the release history it looks like the last breaking change release was made 2020-08-31 in the form of release 0.5.0. So according to the maturity matrix we are free to make a release which is not backwards compatible for metrics when we want.
My proposal would be:
This change would also model for metrics to actually be Stable according to the maturity matrix.
If something like this doesn't occur there is a strong risk of slippage on the whole metric roadmap. Which wouldn't necessarily be the end of the world, but estimates might need to be re-considered.
The text was updated successfully, but these errors were encountered: