Skip to content
返回维护与 LTS

LTS 策略

定义哪些发布是 LTS、支持多久、"支持"意味什么（仅安全 vs 含 bug 修复）。

为什么

无 LTS 策略则每用户问题 — "v14 得安全修复？""v16 支持多久？"— 临时、不一致、有时错地答。策略使支持成契约：LTS 发布被指定（如每偶大版本）、支持声明窗口（如 30 个月）、带声明修复范围（安全 + 关键 bug，非新功能）。这使企业用户能按其节奏规划升级（他们不能每 6 个月升），且你队能可预测分配维护产能。策略还防每发布永支持的失败模式 — 那不可能 — 使 EOL 成声明沟通日期非慢慢淡入忽视。

何时使用

首个企业用户问前。在文档发布策略并从每发布说明引用。

如何做

1. 指定 LTS 发布：如每偶大版本（v16、v18、v20）是 LTS；奇大版本仅"当前"
2. 定支持窗口：LTS = 发布起 30 个月；当前 = 6 个月
3. 定修复范围：LTS 得安全 + 关键 bug 修复；无新功能、无非关键 bug
4. 定节奏：LTS 每季度一补丁发布（或关键 CVE 时）
5. 在 docs/LTS.md 发布策略带支持表：版本、类型、发布日期、EOL 日期
6. EOL 前 6 个月用同弃用渠道（头、邮件、博客）沟通
7. 跟踪采用：若 >20% 用户在 EOL 版本则延或更硬沟通 — 别直接断

示例

# docs/LTS.md
## 策略
- LTS：每偶大版本（v16、v18、v20），支持 30 个月
- 当前：每大版本，支持 6 个月（到下 LTS 的升级路径）
- 修复范围：LTS 仅得安全 + 关键 bug；无新功能

## 支持表
| 版本  | 类型    | 发布       | EOL        | 状态     |
|-------|---------|------------|------------|----------|
| v20   | LTS     | 2024-04-01 | 2026-10-01 | 活跃     |
| v19   | 当前    | 2023-10-01 | 2024-10-01 | EOL 将至 |
| v18   | LTS     | 2022-10-01 | 2025-04-01 | 活跃     |
| v17   | 当前    | 2022-04-01 | 2022-10-01 | EOL      |
| v16   | LTS     | 2021-10-01 | 2024-04-01 | EOL      |

# LTS 补丁发布（季度，仅安全 + 关键）
# v18.20.1 — 从 v20 回移植 CVE-2024-1234 修复
# changelog："v18.20.1 (LTS)：CVE-2024-1234 安全修复"

常见问题

  • ⚠每发布永支持 — 不可能但团队从不声明 EOL 尝试，维护产能薄摊 5 版本。
  • ⚠LTS 得新功能 — 那不是 LTS 是 fork，支持窗口无意义因 API 持变。
  • ⚠无 EOL 沟通 — 用户在 CVE 不修时发现无支持，这是最坏的了解方式。

最佳实践

  • ✓发布带 EOL 日期的支持表并从每发布说明引用 — 用户不应问"v18 还支持吗"。
  • ✓LTS 意仅安全 + 关键 bug，绝不新功能 — LTS 得功能那刻是 fork 策略破。
  • ✓EOL 前 6 个月沟通并跟踪采用 — 若 >20% 在 EOL 版本则延而非弃。