How is the gap between different "versions" between server and client handled?

[ryuheechul]

Very new to tRPC and still trying to understand it to consider for future usage.

I like that server and client are tightly coupled which is great for development time.

But how is the gap between the deployment sync is being handled?

For example a parameter once was a become b with next commit for both server and client.

I'm excluding the mono deploy case here (e.g. client page is rendered from server process directly rather than a being static page (via S3 for example) since in this case there is no impedance mismatch here.

I would imagine that even when your CI deploy the servers and client exactly at the same time, the time of completing and therefore user's accessing them are different. Let's client was deployed first and server was deployed 5 seconds later (and this is actually one of the simplest case and it could be very easily worse than this - client is loaded before this deployment happened so remained stale).

Then client would try to use b when there is no b but just a will be returned.

Traditional approaches seem to solve this by never changing what's already being used and bump the version in case the change is necessary.

What's the tRPC's take on this? Is there any suggested solution? Perhaps there is a versioning on procedures that I'm not aware of?

I guess I can imagine a bit crude way to avoid conflict would be duplicate the procedure and use the new name for new client version and remove the old one when it's not expected to be called any more from any stale client.

Curious what other approaches that people are taking for this.