The assumption is that you roll out clients and servers at different times, and then once you feel they are stable, roll out the counter part. In effect, you can only roll back one or the other at a given time, but no negotiation is needed. Also, in general its better to be indefinitely backwards compatible, because there still tend to be clients, or servers, that will never upgrade. It's more work in the mean time, but it pays dividends over time. Users *really* like backwards compatibility. It's just us developers that feel the pain for it.
On Friday, June 24, 2016 at 8:46:20 AM UTC-7, Scott Devoid wrote: > > Thank you for the reply. > > > ... Also all servers will > > need to be updated before releasing it in the clients. > > > > Always make sure that each client can work with the current server > version > > and the next server version. Serves must work with the current client > and > > the next client. This forms a chain of compatibility that makes rolling > out > > new versions easy and makes rolling back safe! > > But in the roll-back scenario if you only have control over the server > you could still get into the situation where the client has a newer > version than the server, right? So it's still necessary for some form > of negotiation. The client needs to figure out that "DoItWayThree" > won't work and fall back to "DoItWayTwo". > > Right now, at least with the Go libraries, the only way to implement > all of this is a lot of boilerplate. I'm hoping there's a better way. > > Thanks, > ~ Scott > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1ecd512c-4fec-4ef8-b707-f441e3ff11db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
