版本字符串不能证明 VPN 插件具备某项功能

三个问题把版本之争与功能排查区分开来：这项功能本应由哪个组件提供，该组件实际安装的是哪个版本，以及它的变更记录对此怎么说。单看插件版本号，这三个问题一个也答不了。那条诱人的捷径——把缩短的版本号与教程里的最低要求作比较——之所以行不通，是因为发行版的版本字符串并不是小数。先想清楚你在比较什么，再去比较。

这项功能可能位于 NetworkManager 中，位于它的 VPN 插件中，位于底层引擎中，也可能位于单独的桌面前端中。这是四个项目，有四套发布历史。

四个组件，四套发布历史

你看到的编辑器通常是一个插件，而插件会调用引擎，例如 OpenVPN 二进制文件或 WireGuard 实现。NetworkManager 本身提供连接模型，桌面前端则可能在其上添加自己的字段。功能可能出现在其中任何一个里，升级其中一个并不会升级其他几个。引擎更新，并不能证明已安装的编辑器可以导入引擎所支持的选项。

从症状出发：字段是在对话框里缺失，导入后消失，还是存在却被忽略？ 这些观察指向不同的组件，也需要不同的证据。

比较之前先拆开版本

Debian 的软件包政策把格式定义为 epoch、上游版本和打包修订号。先比较 epoch，再比较上游部分，最后比较修订号，依据的是软件包管理器自身的排序规则，而不是十进制算术或简单的字母排序。波浪号排在一切之前，包括该部分的末尾，正因如此候选版本会先于正式版本。把各部分分开来读，比较才有意义。

不要为某种让 0.8.999 看起来接近 0.9 的其他方案发明换算规则。数字接近并不能证明内容。

问清楚安装的是什么、本应是什么

apt-cache policy 会报告你指定的每个软件包的已安装版本、候选版本以及各自来自哪个仓库。引擎和插件都要读，并且记录完整字符串而不是缩写形式。本地元数据可能已经过时，候选版本也不能证明某个正在运行的进程已经加载了那个构建。如果升级后服务没有重启，磁盘上的文件和观察到的行为可能对不上。

然后阅读对应的变更记录。打包修订号可以在不采用新上游版本号的情况下携带补丁，而这正是版本看起来没变、行为却不同的情形。

在拥有该功能的组件中验证它

遇到导入问题时，要检查已安装插件支持的字段和保存下来的结果，而不只是对话框。标签、原生数据字段和引擎参数可能是同一项设置的三种表示；成功导入一个文件，并不说明每条指令都保留了下来。请把功能说清楚：例如，接受这条指令，同时保留它的认证含义。

如果该发行版支持的构建缺少这项集成，请选择经批准的更新路径或换一个客户端。混用其他发行版的仓库，或者为了抬高可见版本号而套用归档的源码补丁，是用版本之争换一个不受支持的系统。

有用的报告会写明发行版、完整的软件包版本、当前连接的所有者、所需的选项以及观察到的保存行为。那才是一个可以复现的问题。