Cilium 长期稳定的「版本发布节奏模型」
Cilium 不是临时拍脑袋发布，它 几乎每个大版本都遵循同一套节奏：
| 阶段 | 典型间隔 |
|---|---|
| pre.x | 每 ~4 周一个 |
| feature freeze | GA 前 ~4 周 |
| rc.0 | freeze 后 ~1 周 |
| rc.1 | rc.0 后 ~2 周 |
| GA | rc.1 后 ~1 周 |
你给的时间线完全符合这个模型：
- pre.3 → pre.4：~5 周（年末假期稍长）
- freeze → rc.0：~6 天
- rc.0 → rc.1：2 周
- rc.1 → GA：~9 天
👉 这是 Cilium 过去 1.14–1.18 一直重复的节奏
二、如何正确理解你列出的 1.19 发布节奏
你给的时间线是 标准 Cilium release 模型，每个阶段角色非常清晰：
🔹 pre.x（pre-release / feature development）
1.19.0-pre.0 → pre.3
这个阶段：
-
允许合并新特性
-
允许较大行为改动
-
PR 数量多、变动面大
-
包含：
- 新 BPF hook
- 新 datapath 行为
- 新 flag / 新 annotation
- 新安全语义（你 PR 所在的典型阶段）
👉 安全风险最大的阶段
🔹 pre.4（Feature Freeze）
1.19.0-pre.4：2026-01-06（feature freeze）
这是一个非常关键的节点：
-
❌ 不再允许引入“新特性”
-
✅ 只允许：
- Bug fix
- Security fix
- 性能修复
- 文档修复
-
所有 feature 必须在这个点之前合并
👉 你的 PR 如果涉及“语义改变 / 安全模型变化”，一定会被拿到这个节点前重点讨论
🔹 rc.x（Release Candidate）
1.19.0-rc.0
1.19.0-rc.1
RC 的含义不是“试试”，而是：
“理论上已经是可发布版本，只是在等社区打脸”
RC 阶段只允许：
- 🐞 回归 bug 修复
- 🔒 安全漏洞修复
- ❌ 不允许任何新行为
如果在 rc 阶段发现：
- 安全模型有歧义
- 默认行为可能破坏已有隔离假设
👉 要么修，要么 rollback，要么延期
