更新
ThinkTerm 不会自行安装更新。它只负责检查、告诉你，然后等你决定。
检查更新
设置 → 软件更新 里能看到全部信息：当前运行的版本、最新发布版本、上次检查的时间，以及更新内容。
检查更新立即执行一次检查。自动更新和检查频率决定它自己多久检查一次——关闭、每天、每周，或者按天、小时、分钟设定的间隔。更新内容打开待安装版本的发布说明，查看全部版本打开完整列表。
检查到新版本时，界面上出现的是一个小圆点，而不是弹窗抢占屏幕。同时会发一条通知——ThinkTerm 有新版本——点击后进入同一个页面。
安装更新
安装更新 会原地替换文件。替换期间你面前的窗口可以继续使用，而 ThinkTerm 仍然运行着启动时的那个版本。
最后这点最容易被误解，所以确认信息把话说明白了：已安装 ThinkTerm x.y.z。退出并重新打开 ThinkTerm 即可使用新版本。 运行中的会话底下不会被偷偷换掉。
谁有权替换这些文件
ThinkTerm 只更新它自己装的副本，也就是通过安装脚本装的那种。其他每一种安装方式都有各自的归属方：系统包管理器、Homebrew、Nix、AppImage 自己的更新器，或者那个运行了 cargo build 的人。对这些情况，ThinkTerm 会指出归属方，而不是覆盖它的文件。
| 这个副本的安装方式 | ThinkTerm 的处理 |
|---|---|
| 安装脚本 | 安装更新，并保持原来的变体 |
手动放置的 ThinkTerm.app | 在原位置替换，并把命令行工具放到 ~/.local/bin |
| AppImage | 提示用 AppImageUpdate，或从发布页下载新的 AppImage |
| Homebrew | 提示运行 brew upgrade thinkterm |
| Nix | 提示通过你的 Nix 配置更新 |
| 系统包管理器 | 提示用 apt、dnf 或原来的方式安装新包 |
| Windows 安装器 | 下载新安装器并运行 |
| 从源码构建 | 提示拉取仓库后重新构建 |
| 无法识别 | 拒绝替换，并提示按原来的安装方式更新 |
命令行
thinkterm update 遵循与设置里那个按钮完全相同的规则。
thinkterm update # 检查，安装前询问
thinkterm update --check # 只报告是否有新版本，不安装
thinkterm update -y # 不询问直接安装
thinkterm update --version X # 安装指定版本 X 而不是最新版，允许降级两条路径都没有重新实现安装器，而是把活交给 install.sh——只有这个脚本了解归档布局，以及桌面版和服务器版之间的切换。脚本是从默认分支拉取的，不是从要安装的那个 release 里取的：这样对安装器的修复能一次性覆盖所有已装机器，而不用等下一个版本发布。
更新远端 server
客户端和 server 在协议发生变化后就无法通信。最常见的触发方式是：你的桌面端升级了，而某台主机上的 server 还跑着上个月的构建。
ThinkTerm 手上已经有到那台主机的 SSH 会话，所以它可以自己修复这个不匹配，而不是把你打发去手动登录。attach 时发现版本不匹配，它会主动询问是否把自己这个版本装到该主机上；它会先读取主机的安装清单，这样对方原本是桌面版安装的话仍然保留 GUI；然后通过第二条 SSH 会话运行安装器，输出实时转发到连接窗口里。
之后运行中的会话会怎样，取决于一个设置：
更新远端 server 时保留会话 —— 运行中的 server 把 pane 交给新版本而不是停掉，里面跑的程序不会中断。
关闭该设置时，ThinkTerm 会在停止旧 server 前询问，因为停止它会结束它持有的所有会话。这件事从不会在未经询问的情况下执行。
交接本身用的就是 远程 里描述的那套机制——运行中的 server 把 pane 传给新的二进制，会话本身察觉不到。