-
Notifications
You must be signed in to change notification settings - Fork 466
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 doc on API stability #4326
Add doc on API stability #4326
Conversation
c38d288
to
7f6283e
Compare
7f6283e
to
ea02735
Compare
ea02735
to
48e460c
Compare
48e460c
to
b6e7aec
Compare
4b57dce
to
b49e6fe
Compare
25fa9f2
to
8c2d7df
Compare
8c2d7df
to
c18f5ab
Compare
c18f5ab
to
1ba118b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@knz ... Breaking this up makes it a lot easier to digest, not to mention a much better navigation experience.
I have a lot of suggestions and changes (information architecture/wording/etc.), so I've made my own branch against this PR, in which I've started going through the files one-at-a-time. Given that we have other release-specific documentation that takes priority over this, I don't know how soon I will be able to go through all of it.
So, my suggestion at this point would be that we open a new PR with the very high-level stuff from this PR (i.e. interface-types.md and overview-of-apis-and-interfaces.md and compatibility-and-programming-guarantees.md), and then start adding the docs specific to the interfaces/guarantees piece-by-piece in separate PR's (i.e. sql-functional-behavior-guarantees.md, introspection-interfaces.md, et al each get their own PR). I can open that new PR that just touches the high-level stuff, and get you and @jseldess to review, and then I can move on to the "interface-specific" PR's. I'm thinking I'd add introspection-interfaces.md to #5454, making that the first "separate PR" that includes stability doc specific to one of the interfaces. I know it won't make much sense writing about "public/programmable", etc, without having designated those categories to each interface, but I think starting with the overview, then with a piece at a time is a good way to push this forward. Thoughts?
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @awoods187, @bdarnell, @danhhz, @ericharmeling, @jordanlewis, @knz, @mjibson, and @rmloveland)
Works for me. The 3 first pages you listed here are the most important anyway. (I would recommend also including the |
cd5fd8f
to
d7a1e5f
Compare
|
Name | Link |
---|---|
🔨 Latest commit | d7a1e5f |
d7a1e5f
to
7a1bdec
Compare
@taroface, given the publication of https://www.cockroachlabs.com/docs/stable/api-support-policy.html, should this PR be closed? |
let's call this a day -- if we want more fine grained mentions of APIs, the folk now owning the areas can spell out their rules themselves now. |
Here is a doc which does two things:
cc @BramGruneir @mjibson @bobvawter @jordanlewis for checking this is aligned with our actual practices so far and aspirations for the future.
cc @rmloveland for further editing and integration in the docs.
cc @bdarnell to sign off on the stability commitments.
cc @rolandcrosby @awoods187 to acknowledge the compatibility and visibility commitments.