Ubuntu Drop背后的故事
概念与由来
在 Ubuntu 社区里，“Drop”并非官方术语，通常指某个版本到达生命周期终点（End of Standard Support，EOSS）后，官方停止常规的安全与错误修复，社区与仓库也会逐步将其移出“活跃”列表。这一机制源自 Ubuntu 自 2004 年起确立的“可预测节奏发布”理念：每 6 个月发布一个版本，且每 **第 4 个版本（即每 2 年）**为 LTS（长期支持），面向大规模部署的稳定性需求。随之而来的，就是按固定日程“到期停止维护”的“drop”节奏。
为何会有 Drop
- 安全与稳定性优先：旧版本一旦出现漏洞，修复成本与风险都会上升。集中资源维护新版本，能更快、更一致地覆盖关键安全问题。
- 资源与生态优化：内核、编译器、图形栈与新硬件适配需要持续投入。将维护力量聚焦在受支持版本，有利于整体生态的兼容性与性能。
- 清晰的升级路径：固定节奏与“到期即止”的策略，倒逼依赖方（企业、云厂商、开发者）采用受支持的版本，减少长尾风险。
- 商业支持的可扩展性：对需要更长时间维护的组织，Canonical 提供 Ubuntu Pro 等付费扩展支持，作为“标准支持到期后的选项”，这也是“drop”并不等于“无人维护”的关键背景。
时间线与规则
- 发布节奏：每 6 个月一个版本；每 2 年一个 LTS。
- 标准支持：LTS 的“Main”仓库标准安全维护期为 5 年；非 LTS 的“临时版本（Interim）”标准安全维护期为 9 个月。
- 扩展支持：
- Ubuntu Pro 可将 LTS 的维护期再延长 5 年（覆盖 Main，通常也覆盖 Universe 的安全修复）。
- 对 Universe 仓库，提供最长 10 年的 ESM（Expanded Security Maintenance）。
- 面向历史遗留需求的“Legacy add-on”覆盖可延续至 第 11–15 年。
- 到期后的“Drop”：标准支持到期后，官方仓库与更新渠道对该版本的常规支持即告停止，进入“扩展支持/付费支持/社区归档”的分层状态，这就是社区俗称的“被 drop”。
典型案例
- Ubuntu 20.04 LTS（Focal Fossa）：标准支持至 2025 年 4 月；通过 Ubuntu Pro 可延至 2030 年 4 月；Universe 的 ESM 可覆盖至 2030 年 4 月；如启用“Legacy add-on”，可延至 2035 年 4 月。
- Ubuntu 24.04 LTS（Noble Numbat）：标准支持至 2029 年 4 月；通过 Ubuntu Pro 可延至 2034 年 4 月；Universe 的 ESM 可覆盖至 2034 年 4 月；如启用“Legacy add-on”，可延至 2039 年 4 月。
- Ubuntu 25.04（Plucky Puffin）：标准支持至 2026 年 1 月；为非 LTS 版本，到期后不再提供常规更新。
上述时间点体现了“固定节奏发布 + 分层维护”的设计：标准支持期内为“在册维护”，到期后则进入“扩展/付费/归档”的轨道。
如何应对版本被 Drop
- 升级到受支持的 LTS：例如从 20.04 LTS 升级到 22.04 LTS 再到 24.04 LTS，以获得更长的安全维护窗口。
- 需要更长时间在旧版本上运行：为 LTS 购买 Ubuntu Pro，继续获得关键安全修复与合规能力。
- 做好变更风险控制：升级前完整备份、在测试环境验证、规划回滚方案，避免业务中断。
- 非关键或隔离环境：可考虑使用容器/虚拟化将旧环境“封装运行”，逐步迁移核心负载。
这些做法与 Ubuntu 的发布与维护策略相衔接：标准支持期内免费维护，标准支持期满后以 Ubuntu Pro/ESM/Legacy add-on 等分层方式延续必要的安全覆盖。
