支持层级

定义层级（如 LTS / 当前 / beta / EOL）使用户知得何支持级别。

为什么

单一"支持"布尔太粗 — 不区分 beta（自担风险）与 LTS（生产就绪、30 月支持）与当前发布（支持但快升）。层级给用户心智模型：可选 LTS 求稳、当前求功能、beta 求预览，每层有声明支持级别（修复范围、响应时间、窗口）。这也让你队正确分配支持产能 — LTS 优先安全回移植、beta 尽力 bug 报告、EOL 无。无层级则每发布同待，意味要么过支持 beta（浪费）要么欠支持 LTS（企业用户走）。

何时使用

野外 >3 并发版本时。在文档随 LTS 策略发布层级。

如何做

1. 定 3-5 层：beta（预览、尽力）| 当前（支持、快升）| LTS（稳、30 月）| EOL（无支持）
2. 每层声明：修复范围（安全？bug？功能？）、响应 SLA、支持窗口、升级期望
3. 每发布在 changelog 和支持表标其层
4. 层转换显式：beta -> 当前 稳定发布时；当前 -> LTS 指定时；LTS -> EOL 窗口结束时
5. 允许用户编程查层：GET /api/version 返 { version, tier, eolDate }
6. 按层分配支持产能：LTS 60%、当前 30%、beta 10%、EOL 0%

示例

# 支持层级（在 docs/LTS.md）
| 层      | 修复范围               | SLA       | 窗口   | 升级     |
|---------|------------------------|-----------|--------|----------|
| beta    | 尽力 bug               | 无        | 3 月   | 到当前   |
| 当前    | 安全 + bug             | 5 天      | 6 月   | 到下个   |
| LTS     | 安全 + 关键            | 2 天      | 30 月  | 可选     |
| EOL     | 无                     | 无        | 0      | 必须     |

# 编程层查询
app.get('/api/version', (req, res) => {
  res.json({
    version: '18.20.1',
    tier: 'LTS',
    eolDate: '2025-04-01',
    supported: true,
  });
});

# changelog 中层转换
## v20.0.0 (2024-04-01)
- 层：LTS（2024-04-01 指定，EOL 2026-10-01）
## v19.0.0 (2023-10-01)
- 层：当前 -> EOL（2024-10-01）— 升到 v20

常见问题

⚠发布无层 — 用户不知 v19 生产安全还是 beta，故要么过慎（跳 LTS）要么欠慎（生产跑 beta）。
⚠所有层同支持努力 — beta 得与 LTS 同 bug 修复优先，浪费 LTS 用户付费的产能。
⚠层转换静默 — v19 无公告变 EOL，用户在 CVE 不回移植时发现。

最佳实践

✓每发布在 changelog 和编程 /api/version 端点标其层 — 用户不应猜支持级别。
✓按层分配支持产能（LTS 60%、当前 30%、beta 10%）— 这匹配企业用户所付。
✓每层转换（当前->EOL、beta->当前）在 changelog + 邮件公告 — 静默转换破信任。