Conda-Build Recipe 格式的变革：在传统与创新之间取得平衡

最近，Conda 指导委员会通过 CEP-13 和 CEP-14 批准了新的 recipe 格式 (v1)，这标志着 conda 生态系统中包管理发展的一个重要里程碑。虽然社区对新格式带来的潜在改进表示欢迎，但我们也承认 v1 recipe 格式仍在 rattler-build 中开发。因此，v0 recipe 格式仍然被广泛使用，这突出了在创新与支持遗留系统之间取得平衡的必要性。

虽然重点是使用 v1 格式进行创新，但过渡和采用需要时间。与此同时，我们仍然需要对那些继续依赖 v0 格式来满足其打包需求的用户的需求和挑战做出响应。v0 格式的更新应以用户社区的需求为驱动，以用户反馈为指导，旨在解决痛点。

要启动对 v0 conda-build recipe 格式的更改，请遵循以下工作流程

1. Conda 增强提案：对 v0 格式的任何拟议修改也应在 v1 格式中提出。理由是，如果 v0 需要它，那么 v1 也应该需要它。所有提案都经过 CEP 流程；请参阅 CEPs。
2. 审查与批准：拟议的修改将经过 CEP 审查和批准流程，并导致 v1 recipe 格式 schema_version 升级。
3. 实施：一旦获得批准，更改就可以在 v0 格式中实施，确保与 v1 格式中的相应功能对齐。

在社区进行从 v0 到 v1 的过渡时，我们的目标是提供清晰的沟通和指导。开发人员和维护人员需要配备必要的资源和支持，以了解新格式的影响，并就何时以及如何迁移做出明智的决策（请参阅 rattler-build 的 recipe 文档、rattler-build 的迁移文档 和 conda-recipe-manager 文档）。

v1 格式的批准代表着 conda 生态系统向前迈出的令人兴奋的一步。然而，必须认识到变革需要时间，并且向新格式的过渡将是渐进的。在此期间，v0 格式仍然是 conda 生态系统的关键组成部分，需要持续的支持和更新。与往常一样，目标是平稳过渡到新标准，同时继续支持现有的基础设施和用户群。