Streamlining mux server versioning

[ahupp]

Is your feature request related to a problem? Please describe. I setup an ssh_domain and connect via wezterm connect <the name>. This failed with an error because the versions of wezterm on each end were different (by one day!). I found the installed version of wezterm on the remote host, updated it, and it continued to fail with the same error. I eventually figured out that there was an existing version of wezterm-mux-server running, after killing it everything worked.

Describe the solution you'd like It would be nice if: a) the check at startup depended on features rather than a strict version check (I realize this makes development harder, so maybe not a great tradeoff but I can dream).
b) Handle the upgrade case more cleanly, either by asking whether to kill+restart, or making the error message more explicit.

[wez]

The critical part of the versioning is the CODEC_VERSION, which is bumped when ABI changes are made:

https://github.com/wez/wezterm/blob/6b67ae842cdd156490b598fe6ce2ce983a70b2a8/codec/src/lib.rs#L416-L419

that is what is checked by the client when it comes to version compatibility; it's not a strict version check.

I think it is reasonable to give clearer and more actionable error messages. Can you share what you saw in this situation?

I think you should be seeing this:

https://github.com/wez/wezterm/blob/bebad33298adbc2a7ce786292829a5bb14b18598/wezterm-client/src/client.rs#L1073-L1078

if so, then perhaps the minimum effort approach is to amend that to suggest killing off the old mux server?

[ahupp]

Ah I see, the error just mentioned the version of the binary so I assumed it had to be exact. Then killing off the old one (iff the binary on disk is newer) seems like a good solution, with or without a prompt.

[loops]

Ah I see, the error just mentioned the version of the binary so I assumed it had to be exact. Then killing off the old one (iff the binary on disk is newer) seems like a good solution, with or without a prompt.

Would just add 2 pennies here to say that automatically killing the old instance will be terminating whatever processes are running under that mux. That seems a bit harsh, considering the user may not appreciate this risk when upgrading their local instance, or connecting from a new client machine that is the only one with the newest version.

At the very least, a prompt should be shown before killing. But hopefully this will seldom happen, so informing the user and leaving it up to them to resolve may be enough.