NetBSD 项目在文档里说了两句互相矛盾的话。一边是刚更新的 release-engineering 页面,明确写着 netbsd-9 分支已经终止支持,不会再有任何安全更新;另一边是安全公告页面,上面还挂着“NetBSD 9.4:Supported”的标签。这不是打字错误,是开源项目治理里一个很常见、也很容易被忽略的漏洞——版本终结的消息,总是比文档更新跑得快。
9.5 是收官版,不是新功能版
NetBSD 9.5 是 9 稳定分支的第五个、也是最后一个发行版。它收录的是 2024 年 4 月 9.4 发布之后所有被认为对安全或稳定性重要的修复,和 9.0 完全兼容,不引入新功能。变更记录文件 CHANGES-9.5 大约 53 KiB,LAST_MINUTE 文件里写得很平静:这次没有额外需要特别说明的问题。这是一次典型的“收尾式”发布——把该修的都修完,然后关门。
关门这件事发生得很同步。release-engineering wiki 页面在近期更新,直接写明 netbsd-9 分支终止支持,项目方敦促所有还停留在这条分支上的用户尽快迁到 NetBSD 11.0(11.1 即将在月底发布)或即将上线的 NetBSD 10.2。9.5 的发布公告和 EOL 声明,几乎是一句话说完的。
官网自己都没对齐口径
这才是最有意思的地方。release-engineering 页面已经把 netbsd-9 判了死刑,可安全公告的“按发行版列出”页面还在把 9.4 标注为受支持版本。一个仍在用 9.x 的系统管理员,如果只查安全公告页,很容易得出“我这个版本还有人管”的错误结论——而实际上不再有任何安全补丁会流向这条分支。
这不是危言耸听式的“开源不靠谱”,而是一个具体的、可核实的治理疏漏:两个官方页面,两套说法,更新时间点没对齐。开源项目的文档往往散落在多个子系统里,发行公告、wiki、安全页面各自维护,谁先更新谁后更新全凭维护者手速,这次刚好露出了缝。
一边说死了,一边说还活着,用户到底该信哪一页?
滚动淘汰,不是 LTS 那套逻辑
NetBSD 的支持模式和 Ubuntu LTS 完全不同。LTS 会提前公布一个固定的多年支持期限,用户可以按日历排迁移计划;NetBSD 通常只同时维护当前主版本和前一个主版本,某条分支什么时候被 EOL,取决于下一条分支什么时候“成熟”,没有预先公布的固定日期。
这种模式对追新的用户几乎无感,但对长期依赖旧分支的嵌入式设备和遗留系统运维者不友好——支持窗口的可预测性天然更低,你很难像用 LTS 那样提前一年排好迁移计划。人无远虑,必有近忧,这句话放在滚动淘汰模式下格外贴切:等到官方发公告才发现分支已经关门,往往已经晚了。
- 提醒.仍在生产环境跑 9.x 的团队,暴露面从公告发布那天起就在持续扩大,不会有补丁再来兜底。
“可以直接升级”不等于“零成本”
官方把 9.5 到 10.2 或 11.0 的路径描述为“通常可直接跨版本升级”,但这句话背后藏着一整套操作:配置文件要跑 etcupdate,系统要过 postinstall fix 检查,所有第三方包都要针对目标主版本重新编译,内核配置、驱动和设备名可能发生变化,部分硬件架构在新版本里的支持程度还可能不如从前。
这套流程决定了迁移到 10.1(当前受支持)、10.2(即将发布)还是 11.0(当前正式版,11.1 月底跟进)不是简单的“选个更高的数字”。跑在冷门硬件架构上的老系统,反而可能要评估等 11.1 落地、绕开 .0 版本常见的初期问题,再动手迁移更稳妥。
NetBSD 9.5 本身没什么争议,一次干净的收尾,该修的都修了。真正值得记一笔的是官方文档内部这道裂缝:release-engineering 页面已经宣布分支死亡,安全公告页面却还挂着生命体征。开源项目习惯把透明度当成天然优势,可透明度的前提是各处文档能对上口径——这次没对上。
其兴也勃焉,其亡也忽焉。一个版本分支的终结原本可以是件安静的事,可安静的前提是所有该更新的地方都真的更新了。9.4 用户如果只信了那页“Supported”,大概不会觉得这事有多安静。