What's the best practices around tRPC to negotiate API-versions?

In my example I'm thinking about having a native app as a tRPC client and a locally deployed docker image as the tRPC server. Both of these are distributed "binaries" that might not be the latest version at any given time. Sooo. is there any best practice on how to identify tRPC "schema" changes so that I could implement api-version-negotitation? With REST I'd do it with a list of endpoints and what versions the server support for each endpoint and let the client match that to what it supports to check if we need to display and upgrade message.
Alex / KATT 🐱45d ago
we started on something to help you with schema drift https://drift.trpc.io/
tRPC Drift
Manage your tRPC API and make sure you don't drift away from your schema.
StefanWallin38d ago
Hello Malmö, Sundsvall calling! But the essence of this is to know when the contract changes, but what approach would you recommend for somehow versioning the contract? My gut tells me to duplicate my trpc-endpoint and schema whenever I make a change and a normal restendpoint claiming what versions the server supports.