That’s correct.
You must either use directly or load via the multi-version API a version of the library that is compatible with the cluster. We don’t currently support loading new libraries after the network is setup, so if you need to add support for a new version at present, then you’ll have to restart your client application.
The current way to manage this is more or less to just know what version your clusters are running and what they are about to upgrade to (possibly managed through some other service).
There is a actually already a protocol version exchange that happens when two processes connect, but this is slightly different than the release version (because multiple release versions can share the same protocol version, as mentioned above, and prerelease versions complicate this even more). And in fact, a cluster could consist of processes running multiple different compatible release versions. I think for the purposes you describe, though, knowing the version of one process would be good enough assuming that the process is truly part of the running cluster. Maybe it’s worth opening up a specific discussion about support for learning a cluster’s version from incompatible clients in order to solicit ideas.
One of the things this doesn’t help you with directly, though, is upgrades. To minimize downtime, you would want your clients to know what new version of the client to use before the upgrade happens, so you would have to have some other mechanism for making that information known.