装了 4.1.9，支持期并不会延长到 4.1.9 发布那天

midPoint 的文档把这句话写得很直白：支持期只适用于 minor/major 版本。维护版本不改变支持期，它自己也没有独立的支持期。支持期从 midPoint 4.1 这类 minor/major 版本发布那天开始计算，4.1.1、4.1.2 都是在这段支持期内发布的维护版本，它们不延长支持期。等到 4.1 的支持期结束，4.1.x 整个家族——4.1.1、4.1.2 以及之后所有维护版本——同时失效。

也就是说，安装一个更晚的补丁版本，不等于把 EOL 往后推。补丁发布的日期与支持截止日没有关系。midPoint 还补了一句：维护版本没有固定节奏，按需发布。所以“等下一个补丁再说”这种策略，在支持期计算上完全不成立。

起算点永久固定在 GA 上

midPoint 的完整规则是：feature release 约每 12 个月发布一个，支持 2 年；LTS 约每 4 年发布一个，支持 5 年，另有 extended support。extended support 更贵，只面向 LTS，而且必须在该版本还在支持期内时谈下来；它只 backport 影响生产的大问题，已经有 workaround 的问题不修。

升级路径上有一点容易忽略：LTS 之间可以直接升级，不必经过中间的 feature release；但升级前要先升到该线最新的维护版本，否则部分 pre-upgrade 检查不可用。维护版本不延长支持期，但它决定升级工具是否愿意继续。

.NET：LTS 和 STS 的代码质量完全一样

.NET 的主版本每年 11 月发布一次，发布时就被定性为 LTS 或 STS。STS 在偶数年发布，LTS 在奇数年发布。STS 以前叫 Current。

这里最反直觉的一点，官方写得很清楚：所有版本的质量完全相同，唯一的区别是支持时长。LTS 给 3 年免费支持和修补程序，STS 给 2 年。不存在“LTS 更稳定”这种说法，只是 LTS 被修得更久。补丁固定在每月第二个星期二发布。

具体日期：.NET 8 于 2023-11-14 发布，终止支持 2026-11-10；.NET 10 于 2025-11-11 发布，到 2028-11-14；.NET 9 是 STS，2026-11-10 到期。策略页面在 https://dotnet.microsoft.com/zh-cn/platform/support/policy 。

Ubuntu：5 年只是默认值，不是上限

Ubuntu 每六个月发布一个新版本，临时版本只提供 9 个月更新。LTS 每两年 4 月发布一次，标准安全维护 5 年，覆盖 main 仓库的 CVE 补丁。

再往后是付费或注册层：Ubuntu Pro 的 ESM 把 main 拉到 10 年，同时把 universe 纳入 10 年覆盖；10 年 ESM 结束后可以购买 Legacy add-on，再加 5 年，总共 15 年。个人用户最多可以在 5 台物理机上免费使用 Pro。

落到具体版本：26.04 LTS 标准安全维护到 2031-05，ESM 到 2036-04，Legacy 到 2041-04；24.04 LTS 是 2029-05 / 2034-04 / 2039-04；22.04 LTS 标准维护到 2027-05。临时版没有 ESM，例如 25.10 的标准维护到 2026-07 就结束了。

升级只支持顺序路径：一个 LTS 到下一个 LTS，或者一个临时版到下一个临时版。LTS→LTS 要等第一个点版本发布之后才开放。发布周期表在 https://ubuntu.net.cn/about/release-cycle 。

Zabbix：5 年里有 2 年只修高危

Zabbix 的 LTS 大约 1.5 年发布一个，支持 5 年，拆成 3 年全面支持（功能更新和安全修复）加 2 年有限支持（仅限高危修复）。标准版本 6 个月发一个，支持 12 个月，其中至少 6 个月全面、6 个月有限。两个 LTS 之间会夹着 2 个标准版本。

EOL 之后还有一段缓冲：已弃用版本在 EOL 后 12 个月内仍可下载，到期后永久移除。另一个常被忽略的条款是对 EOL 操作系统的支持——不承诺延续到原始目标版本之后，有商业合同的除外。

当前表里：Zabbix 8.0 LTS（2026-11-05）全面支持到 2029-11-30，有限支持到 2031-11-30；7.0 LTS（2024-06-04）是 2027-06-30 / 2029-06-30；7.4（2025-07-01）全面到 2026-11-12、有限到 2027-05-31；6.0 LTS 的全面支持已于 2025-02-28 结束，有限支持到 2027-02-28。策略页：https://www.zabbix.com/cn/life_cycle_and_release_policy 。

Jenkins LTS：没有 EOL 这个日期

Jenkins 每 12 周选一个相对较新的版本作为基线 X，创建分支后生成 X.1、X.2、X.3。改动只收在主线“战斗测试”超过一周的最好的 Bug 修复。三个次要版本在四周周期内发完，候选版本在次要发布前两周出现；基线选择本身要持续 2–5 周，所以 X.1 通常在基线发布 6–9 周后才出来。

backport 申请用 lts-candidate 标签；被移植的改动打 2.46.2-fixed，被拒绝的打 2.46.2-rejected，后者也可能在后续 LTS 中被采用。安全修复只进当前 LTS 线，没有固定的 EOL。

LTS 和 weekly 互相切换时，比较的是版本号，不是发布日期。从 LTS 切 weekly，要确保目标 weekly 在所用 LTS 之后发布；从 weekly 切 LTS，要确保目标 LTS 基线比当前 weekly 新。2.5、2.18、2.46 可以升到 LTS 2.46.x；但 2.47 降到 2.46.x 就可能出问题，哪怕 LTS 发得更晚。Jenkins 内部的存储方式决定了通常只能升不能降。切换后要点一次“立即检查”刷新更新站点元数据。文档：https://www.jenkins.io/zh/download/lts/ 。

RHEL：三阶段之后才是 ELC

RHEL 的 10 年生命周期分三段：Full Support、Maintenance Support、Extended Life Phase，之后才是可选的延长支持。维护支持阶段不再计划新功能和新硬件支持，也不出次版本；延长生命阶段没有 bug 修复、安全修复、硬件启用和根因分析，只对现有安装提供支持。

从 RHEL 9 起，延长支持统一成 ELC：为符合条件的偶数次版本从 GA 起提供最长 6 年。名单是 9.2/9.4/9.6/9.8/9.10，以及 10.2/10.4/10.6/10.8/10.10，其中 SAP 客户从 10.6 起可用。RHEL 8.10 只走 ELC Premium。ELC 之后再接 LL，按年续订。生命周期表在 https://access.redhat.com/zh_CN/support/policy/updates/errata 。

OpenHarmony：主动维护期和被动维护期

Release 分支生命周期 2 年（1+1），LTS 分支 3.5 年（2+1.5）。前一段是主动维护期，例行规划维护标签版本，合入缺陷修复和安全漏洞；后一段是被动维护期，不再主动规划和发布标签版本，只修复社区严重以上的安全漏洞和缺陷。发布管理仓库：https://github.com/openharmony/release-management 。

EOL 之后盘上到底发生什么

以 Ubuntu 为例。EOL 后包被迁到 old-releases.ubuntu.com，apt update 打 archive.ubuntu.com 会直接 404。盘上的包索引会慢慢过期，但 unattended-upgrades 的定时器照跑，日志里持续写：

No packages found that can be upgraded unattended and no pending auto-removals

看起来在打补丁，实际一个都没打。这是最容易骗过监控的地方——服务在跑、定时器在跑、日志有输出，只有 404 藏在 apt 的输出里。

台账上该记什么

每个依赖项记四个字段：当前支持线（minor/major 或 LTS 名称）、起算日或 GA 日、标准截止日、是否有 ESM / ELC 这类付费延长。四个字段缺一个，截止日就没法算。

“能下载”“能启动”“云厂商还能开机”都不等于受支持。EOL 之后继续跑，要有网络隔离，并且指定明确的风险承担人，而不是默认“反正还在跑”。

对没有固定 EOL 的产品——macOS、Jenkins LTS、Terraform CLI 这类——不要记一个死日期，记官方更新页和安全公告的订阅方式，按发布节奏去跟。