在 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 审查没有思考到的问题
-
可降级性：
- 对象的构造和语义可能会在将来的版本中变更；变更产生时，降级路线将会被记录；
- 在一些状况下，对象会被主动的转化为新的版本；而在另一些状况下，可能须要人工降级；
- 人工降级可能要求依赖新性能的局部下线，并要求手动将对象转为新版本；
- 人工转化时，须要提供文档记录转化过程；
- 集群可靠性：因为该性能目前具备 e2e 测试，所以通过 flag 启用性能，并不会造成其余不想关性能的 bug；然而因为是一个新性能，所以可能会有一些次级 bug
- 反对：我的项目承诺会实现这个性能，个别在接下来的一个稳固版本中；个别会在 3 个月之内实现，有时可能会更久；公布的版本应该至多在一个次级公布周期中，同时反对两个练习的版本（比方
v1beta1和v1bata2, 或v1beta2和v1），这样用户能够有足够的工夫来降级 - 倡议的应用场景：长期的测试环境；也能够短暂的部署在生产环境以获取用户反馈
Stable Level
- 对象版本：格局为
vX, 其中X是整数（比方：v1）的 API 版本命名 - 可用性：官网公布版本中存在，默认开启
- 用户：所有用
- 完整性：必须在开释的一致性配置文件中，进行 SIG 架构批准的一致性测试（比方：不可移植或 可选性能，可能不再默认的配置中）
- 可降级性：只有具备严格兼容性的变更才容许在接下来的公布版本中退出
- 集群可靠性：高
- 反对：该 API 版本竟在接下来的很多公布版本中存在
- 倡议的应用场景：任何场景