没有孵化器的不稳定 API¶
我们希望取消孵化器，但缺乏稳定化新 API 的替代流程。
问题描述¶
孵化器采用复制粘贴代码的方式，弊端在于——最终会在多个项目中出现需要更新的复制代码，并且可能导致偏差——特别是，我们经常发现项目编辑了它们本地的副本，同步起来很困难。
提议的变更¶
启动新项目时，立即创建库。在库的早期演进过程中，使用库内的 API 命名空间提供对多个 API 版本的并发访问，毕业则涉及在库的顶部公开 API。CI 检查将让我们评估在消费者不再使用它们时删除临时 API 版本的冲击。
在采用临时版本发布时，项目版本将导致我们保留临时版本一段时间——符合正常的向后兼容性考虑。
一旦项目完成早期演进并准备好稳定其 API，它们将发布一个 1.0.0 版本，不带命名空间的 API。
API 更新策略¶
非破坏性更改将正常进行。早期演进期间的破坏性更改将创建一个新的 API 命名空间，使用序列号——1、2、3 等。
代码结构¶
每个不稳定的 API 版本将位于项目的子目录中，以及其测试。
例如，如果一个名为 fred 的新库有两个不稳定的 API 版本，代码树将如下所示
fred/
fred/v1
fred/v1/tests
fred/v2
fred/v2/tests
其中 v2 从 v1 的副本开始，并且 v1 从那时起被冻结。
使用命名空间版本¶
代码应按如下方式导入
from fred import v1 as fred
入口点¶
如果一个库将其 API 的一部分消耗入口点，那么在 API 处于命名空间期间，入口点也必须以相同的方式处于命名空间。
fred.v1.extensionname
备选方案¶
从一开始就稳定¶
我们可以从第一次提交就应用语义化版本控制。大家对这会对开发产生的影响表示了极大的担忧。
使用库名命名空间¶
与其在一个分发中拥有多个版本，不如对库的名称进行版本控制。例如，fred0、fred1、fred2 等，直到 API 稳定。但这会污染全局命名空间，并且需要对全局依赖项进行大量更改，使其摩擦力很大。
Impact on Existing APIs¶
我们需要一个工具来警告在 oslo 项目中使用旧于最新 API 版本的情况：就像今天的自动从孵化器更新脚本一样。
安全影响¶
使用孵化中的代码的旧版本可能稍微容易一些。
性能影响¶
包会稍微变大（类似代码的多个副本），但磁盘上的副本数量会减少（因为它们不会被复制到每个项目中）。
Configuration Impact¶
无
开发人员影响¶
项目将不再能够对孵化项目进行本地更改，而是需要与 oslo 合作，从一开始就集中进行更改。
现有工作流程将会改变，因此我们需要有效地进行社交和沟通关于这一变化。
Testing Impact¶
没有影响。
实现¶
负责人¶
应 Dims 的要求编写，目前没有志愿者执行。
- 主要负责人
<launchpad-id 或 None>
- 其他贡献者
<launchpad-id 或 None>
里程碑¶
完成目标里程碑
工作项¶
在 olso 文档中的某个地方记录此内容
编写更新/lint 工具来检查是否正在使用最新版本。
盈利。
孵化¶
不适用 - 完全取代孵化。
文档影响¶
据我所知，没有。
依赖项¶
没有依赖项，但与弃用策略会有轻微的交互——即我们会尽快发布我们想要删除的内容。有关详细信息，请参见上文。
参考资料¶
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
