Kubernetes 官博宣布，版本发布团队合并了一个 Kubernetes 增强提案（KEP），将版本发布周期由每年 4 次调整为每年 3 次。为什么会进行这样的调整呢。官博解释到，随着 Kubernetes 项目的成熟，每个周期的增强功能在变多，这给贡献者和发布团队带来了不少的负担。与此同时，版本更新频繁也会给下游消费者跟供应商带来不少诸多挑战。他们需要不断升级更新到功能丰富的新版本。
同时，这一政策的落实也会缩减 SIG 发布和发布团队的开销，将精力更多地放在提升软件版本发布质量及工具上。
具体都有哪些改变？
从 Kubernetes 1.22 开始，一个轻量级策略将推动每个发布计划的创建，该政策规定：
  • 一个日历年的第一个 Kubernetes 版本应该在 1 月的第二个或第三个星期开始，为人们从寒假回来后提供更多的空间；
  • 一个日历年的最后一个 Kubernetes 版本应该在 12 月中旬完成；
  • Kubernetes 发布周期的长度约为 15 周；
  • KubeCon + CloudNativeCon 的一周不被视为 SIG Release 的“工作周”。发布团队在此期间不会召开会议或做出决定；
  • 每个周期之间将强制执行至少两周的明确 SIG 发布中断。
因此，Kubernetes 将遵循每年三个版本的节奏。Kubernetes 1.23 将是 2021 年的最终版本。下面的基于该政策预测的版本更新计划时间表：
这些更新日期仅反映开始和结束日期，并且可能会发生变化。发布团队将在每个发布开始时选择增强冻结、代码冻结和其他里程碑的日期，此外，该项政策并不是一个LTS。具体详情可以访问：https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/
文章转载：CSDN（ID：CSDNnews）
（版权归原作者所有，侵删）
点击下方“阅读原文”查看更多
继续阅读
阅读原文
关键词
发布团队