-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Spanner Beta #4028
Spanner Beta #4028
Conversation
From #4027, which this PR supersedes: Draft release notes: google-cloud-spanner 0.27.1
Internal housekeeping not included in release notes:
|
@lukesneeringer @jonparrott We also want a quick review of the API Reference docs to make sure it's reasonably in sync with the client library. This is just for the manual docs; the autogen docs should be fine. |
@lukesneeringer is this ready for me to review the docs? |
@jonparrott Yes. |
Thanks @lukesneeringer, @tseaver, and @jonparrott. |
Non-documentation issues/concerns
Documentation issues (these may be deferred by moving them into their own bugs):
|
Thanks for your detailed review @jonparrott! @lukesneeringer is the "Non-documentation issues/concern" a breaking change to fix later. I'm assuming consistency is important here; what do you think? @tseaver It seems like documentation items 2-6 (shown as 1-5 due to the graphic) should be fixed before the Beta release. The other presentation and organizational concerns can be fixed before GA. Do you agree @jonparrott and @lukesneeringer? FYI @vkedia |
Item 6 should really be fixed ASAP. |
@jonparrott I see what you're saying with that. The Python API Reference combines manual and GAPIC at the same level, whereas the Ruby docs (and those for other languages) puts it another level below under @lukesneeringer Is this particularly difficult to fix with the current docs setup? I don't think we want to create a lot of work to finalize docs for Beta, but I do see the usability concern that Jon is raising. |
Putting in PRs for these. |
Okay, I fixed all of these except the @jonparrott, I am having trouble deciding what to do about the With Pub/Sub, we were breaking everyone anyway, so it was an obvious decision. Additionally, since Pub/Sub was a thin client, it was quite necessary to do this. I am willing to do it here also, but due to the potential customer randomization, as well as the thicker client, it is less clear to me that it is the correct path. Please advise. :-) |
I think we need to make a firm decision on the api -> api_{version} going forwards - either it's a direct alias or it adds functionality. Either spanner or pubsub will need to change. I strongly think we should follow what pubsub did - spanner is transitioning into beta so breaking is allowed (although less than ideal, sure). |
fwiw, the pubsub samples use |
Okay, I am happy to change it then. :-) |
Thanks, @lukesneeringer for fixing just about everything. I agree that I'm happier with all the What's the PR for the alias fix? |
There is not one yet. I had wall-to-wall meetings followed by lunch. :-) |
Understood. Must be Monday. Lots of meetings. |
@jonparrott @bjwatson Okay, #4064 exists. This is probably a breaking change at the margins. In other words, most users will not be affected, but some might be. In particular, we did have at least one doc that told users to Do we need any kind of migration guide? |
@lukesneeringer We should at least have release notes that explain this breaking change. |
@bjwatson We will have release notes either way. :-) |
Woo hoo! Great job @lukesneeringer, @tseaver, and @jonparrott! |
This shall be the "root" PR for getting Spanner to beta. Multiple PRs are going to be made using it as a base.
The remaining to-do items are:
Update documentation to include autogen API reference.(superceded by Update Spanner auto-gen layer. #4033)setup.py
and appropriate documentation to claim beta status. (Bitflip to beta. #4034)Pin gRPC to < 1.6(superceded by Move the admin database GAPIC to source delivery. #4029)