发布周期

在 Gateway API 1.2+ 中，我们将遵循一个更加结构化和可预测的发布周期，该周期借鉴了 上游 Kubernetes 发布周期.

目标

• 确保可预测的发布时间表，使每年能够发布 2-3 个版本
• 最大程度地减少上游 API 批准者所需的时间，并使其更加可预测
• 避免在发布范围的最后时刻进行添加
• 通过要求 GEP 在添加新 GEP 之前离开或毕业，来防止实验通道增长
• 确保 SIG-Network TL 在整个过程中都参与其中，并在发布前获得有意义的机会审查更改
• 向所有人提供更多预先通知（SIG-Network TL、文档审阅者、实现等）

阶段

1. 范围确定

时间表： 4-6 周

在此阶段，Gateway API 维护者和社区将负责确定我们要包含在发布中的功能集。尽管我们始终可以在此阶段之后缩小范围，但我们将在后期避免扩大发布范围，除非绝对必要（设计中的重大缺陷、安全问题等）。

此阶段的一个关键指导原则是，我们要避免扩大实验发布通道的规模。这意味着每个新的实验性功能都应该伴随着已在实验通道中的增强功能的毕业或删除。

请注意，在许多情况下，此范围确定工作将需要对 GEP 进行一些初步工作，以确定它们的生存能力，然后再承诺将它们包含在发布中。

2. GEP 迭代和审查

时间表： 5-7 周

在此阶段，Gateway API 社区将努力更新 GEP 并满足每个已确定在发布周期范围内功能的毕业标准。在开发新功能时，我们将在此过程中将这些讨论带到更广泛的 SIG-Network 会议中，以征求反馈。如果 GEP 在此阶段结束时未达到目标状态，它将从发布范围中删除。

3. API 细化和文档

时间表： 3-5 周

此阶段完全专注于将 GEP 中定义的概念（上一阶段）转换为 API 规范和文档。这为 Gateway API 社区提供了最后一次机会来细化已在 GEP 中商定的细节，但此阶段的任何修改都应该很小。如果文档或 API 规范在该阶段结束时未合并，则此增强功能将从发布范围中删除。

4. SIG-Network 审查和发布候选版本

时间表： 2-4 周

此阶段正式开始于在第三阶段提前几周与 SIG-Network TL 安排的审查会议。在该审查会议中，Gateway API 维护者和 SIG-Network TL 应该就以下事宜达成一致

1. 任何阻止初始发布候选版本的因素
2. SIG-Network TL 希望审查此发布中的任何更改的时间（如果有）
3. 我们可以假设惰性共识并继续进行最终 API 发布的时间

一般来说，我们期望每个次要发布之前都会有两次发布候选版本。这些发布候选版本将使实现能够针对我们的发布进行测试，解决任何错误，并收集有关发布可行性的早期反馈。

每个阶段都欢迎贡献

下表说明了哪些类型的贡献将受到欢迎。对此将有一些例外，但这应该是一个有用的总体指南

	1. 范围	2. GEP	3. API	4. 审查
新的 GEP	✅	❌	❌	❌
重大的 GEP 更新	✅	✅	❌	❌
GEP 细化	✅	✅	✅	❌
API 规范添加	❌	❌	✅	❌
新的一致性测试	✅	✅	✅	❌
错误修复	✅	✅	✅	✅
文档	✅	✅	✅	✅
审查	✅	✅	✅	✅

时间表

鉴于以上情况，我们预计每次发布将需要 14-22 周（4-5 个月）。至少在最初，Gateway API 维护者将在我们开始阶段时为每个阶段设置结束日期。在未来的发布中，我们可能会选择提前设置发布的所有日期。