Kubernetes中API的不同版本， Alpha, Beta, Stable 都是什么（） kubernetesapi

在Kubernetes开发中，我们经常可以看到不同的版本如：alpha, beta, stable 。那么这些不同的版本有什么区别呢？
我在 https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions 这里找到了答案，以下是此部分翻译内容：
新功能的开发经历了以下一系列的状态，不断发展成熟：
Development Level 开发级别

对象版本：没有规定
可用性：不会提交到主要的kubernetes仓库，因此在官方的正式发布版本中并不可用
用户：其他在此功能和概念上有紧密合作的开发者（比如client的开发者）
可升级性，可靠性，完整性，和支持：没有要求和保证

Alpha Level

对象版本：包含alpha 的API版本命名（比如：v1alpha1）
可用性：提交到了主要 kubernetest 仓库；出现在正式的发布版本中；功能是默认出于非启用状态，但是可以通过 flag 启用
用户：开发者以及一些希望对早期功能给出反馈的专家用户
完整性：一部分API操作，CLI命令，以及UI支持也许还未实现； API还未经过 API审查（即，在一般的代码审查的基础上，对API进行深入的，有针对性的审查）
可升级性：
- API对象模式和语义可能在未来的版本中变更，无需在现有的集群中保留该对象；
- 移除可升级性的担忧可以方便开发者快速的进行开发；特别的，API版本可以比miner release（次要发布）更快节奏的增加，并且开发者不需要维护多个版本；
- 当API对象的模式和语义以不兼容的方式变更时，开发人员需要增加API版本
集群可靠性：由于功能相对较新，所以可能缺乏完全的e2e测试，通过flag的方式启用功能可能会暴露一些集群不稳定的bug（比如，一个在控制循环（control loop）的中的bug可能造成迅速创建过多的对象，导致API存储资源耗尽）
支持：并不保证一定会完成改功能，该功能可能会在未来的版本中完全被弃用
建议的使用场景：因为其可升级性问题，以及缺乏长期支持的问题，该版本API只建议临时的测试集群使用

Beta Level

对象版本：包含 beta 的API版本命名(比如：v1beta1)
可用性：官方发布版本中存在，默认开启
用户：对于提供反馈感兴趣的用户
完整性：所有的API操作，CLI命令以及UI支持都应该实现了；具有完整的e2e测试；API已经过API审查并通过，虽然beta期间使用经常会冒出API审查没有考虑到的问题
【Kubernetes中API的不同版本， Alpha, Beta, Stable 都是什么（）】可升级性：
- 对象的结构和语义可能会在未来的版本中变更；变更发生时，升级路线将会被记录；
- 在一些情况下，对象会被自动的转化为新的版本；而在另一些情况下，可能需要人工升级；
- 人工升级可能要求依赖新功能的部分下线，并要求手动将对象转为新版本；
- 人工转化时，需要提供文档记录转化过程；
集群可靠性：因为该功能目前具有e2e测试，所以通过flag启用功能，并不会造成其他不想关功能的bug；但是由于是一个新功能，所以可能会有一些次级bug
支持：项目承诺会完成这个功能，一般在接下来的一个稳定版本中；一般会在3个月之内完成，有时可能会更久；发布的版本应该至少在一个次级发布周期中，同时支持两个练习的版本（比如 v1beta1和v1bata2, 或 v1beta2和v1），这样用户可以有足够的时间来升级
建议的使用场景：临时的测试环境；也可以短暂的部署在生产环境以获取用户反馈