Skip to content
返回维护与 LTS

生命周期终止 (EOL)

声明并沟通版本支持终止，带清晰升级路径和宽限期。

为什么

EOL 不可避免 — 你不能永支持每版本 — 但非受管 EOL 是信任破坏：v16 用户在关键 CVE 不修时发现无支持且从无机会升。受管 EOL 是沟通事件：EOL 日期发布时声明（"v16 EOL 2024-04-01"）、前 6 月和 1 月提醒、当日版本得最终安全补丁 + 指向升级路径的弃用头。宽限期 — EOL 后为升级中用户继续回移植关键安全修复 3-6 月 — 是区分人道 EOL 与悬崖之差。信你 EOL 流程的用户会采用你 LTS；被烧过的不会。

何时使用

每版本，发布时（声明 EOL 日期）和 EOL 时（执行沟通 + 最终补丁）。

如何做

1. 发布时：在 changelog 和支持表声明 EOL 日期（从 LTS 策略导）
2. EOL 前 6 月：邮件该版本所有用户 + 博客 "v16 6 月后 EOL — 升到 v18"
3. EOL 前 1 月：升级 — 该版本每 API 响应弃用头 + 直接邮件滞后者
4. EOL 当日：发最终安全补丁（若有待）+ 设弃用头 + 支持表更新为 EOL
5. 宽限期（3-6 月）：仅继续回移植关键安全修复；沟通此为最后宽限
6. 宽限期后：任何修复皆无；版本真 EOL
7. 保 EOL 版本文档在线带显著 "EOL — 升到 vX" 横幅使用户不搁浅

示例

# v16 的 EOL 时间线（LTS，EOL 2024-04-01）
# 发布（2021-10-01）：声明 EOL 日期
changelog："v16.0.0 (LTS) — EOL 2024-04-01"

# 前 6 月（2023-10-01）：邮件 + 博客
email(subject: "v16 6 月后 EOL — 升到 v18")
blog："v16 于 2024-04-01 终止支持。升级指南：docs/upgrade-v16-v18.md"

# 前 1 月（2024-03-01）：升级
app.use((req, res, next) => {
  if (req.appVersion.startsWith('16.')) {
    res.set('Deprecation', 'true');
    res.set('Sunset', 'Mon, 01 Apr 2024 GMT');
  }
  next();
});

# EOL 当日（2024-04-01）：最终补丁 + 宽限期
changelog："v16.20.5（最终 LTS 发布）— EOL。关键安全回移植续至 2024-07-01（宽限）。"
# 2024-07-01 后：无修复。文档在线带横幅：
# "v16 已 EOL。升到 v18 — docs/upgrade-v16-v18.md"

常见问题

  • ⚠发布时不声明 EOL 日期 — 用户无法规划，EOL 成破信任惊吓。
  • ⚠EOL 无宽限期 — 升级中用户在迁移窗口（可数月）得零安全修复。
  • ⚠EOL 文档下线 — 卡在 EOL 版本（无法立即升）的用户失参考真搁浅。

最佳实践

  • ✓发布时声明 EOL 日期并在前 6 月和 1 月提醒 — 用户不应被 EOL 惊。
  • ✓EOL 后提供 3-6 月宽限期回移植关键安全修复 — 这覆盖升级中用户无需承诺无限支持。
  • ✓EOL 文档在线带升级横幅 — 搁浅用户仍需参考且横幅驱动他们升。