conda-forge 正在迁移到一个新系统，用于生成核心依赖树 (CDT) 软件包。这些变更包括

• CDT 软件包将不再使用 feedstock 构建，此做法已正式弃用。
• feedstock 中的任何当前 CDT 软件包都将移至新的 conda-forge/cdt-builds 仓库，并且 feedstock 将被存档。核心成员将根据需要缓慢地执行此操作，因此可能不会立即发生。
• 新的 CDT 请求应作为 PR 提交到 conda-forge/cdt-builds 仓库。

进行这些更改是为了使 conda-forge 可以为 linux-64 构建提供对 CentOS 7 / glibc 2.17 的访问。它们还将把 conda-forge 构建所需的更多软件包移入 conda-forge 频道，从而使构建更可靠。

conda-forge 正在 macOS 上迁移到 clang 10！查看版本说明，了解新功能、重大更改或已弃用的功能。

通过 CFEP-18，我们现在有了关于如何处理静态软件包的政策。这里最重要的变化是，我们将从主软件包中移除静态库，并将它们移动到带有 -static 后缀的软件包中。-static 软件包默认情况下不会构建，而仅在请求时构建。

cf-mark-broken 仓库已重命名为 admin-requests。它仍然用于相同的目的。但是，我们扩展了仓库的功能，使其能够将软件包标记为未损坏。

我们正在更改将软件包标记为 broken 的方式，以更好地匹配 defaults 频道，并更好地支持依赖于损坏软件包的可重现环境。现在，我们将向软件包添加 broken 标签，但将它们保留在 main 频道上。为了确保它们不出现在 main 频道的 repodata.json 中，我们将修补 repo 数据以使用 removals 功能删除它们。用户将注意到以下更改

• anaconda.org 上的软件包现在将同时具有 main 和 broken 标签。
• 所有将软件包标记为损坏的请求都必须发送到 cf-mark-broken 仓库。
• core 成员不再可以手动将事物标记为损坏，因为还必须进行 repo 数据修补。
• 损坏软件包的软件包元数据可能与它们在 main 频道上时略有不同。
• 现在，软件包元数据的唯一正确来源是 anaconda.org 上的 repodata.json 等。任何其他来源都可能缺少关键更改。

从本周开始，我们正在更改将软件包上传到 anaconda.org 的方式。我们将从直接上传到 conda-forge main 频道转变为使用暂存组织/频道，并结合从暂存频道到生产频道的复制请求。这个新流程将允许我们在 feedstock 的输出发布之前对其执行一些验证。

作为 feedstock 维护者，您会看到什么？

• 从本周开始，admin-migrations 服务将向所有 feedstock 提交 commit，以向它们提供必要的配置、API 密钥和令牌。
• 现在将为每个 feedstock 提供一个密钥令牌。此令牌不应共享或从 CI 服务中取出。它用于在上传过程中识别 feedstock。
• admin-migrations 服务将在 conda-forge.yml 中设置一个新的顶级键 conda_forge_output_validation: true。此键向 conda-smithy 指示它应在 feedstock CI 脚本中包含输出验证调用。
• 当前打开的 PR 将需要手动添加此键，然后重新渲染。
• 当 PR 运行 CI 脚本时，它们将对 feedstock 输出进行一些初始验证。如果此验证失败，CI 作业将失败。请查看 CI 日志以获取在 conda-build 运行后打印的错误消息。
• 一旦 PR 合并到 master，从暂存频道到生产频道的复制将自动发生。
• 如果复制请求失败，您将通过对 master 的 commit 的评论收到通知。
• 作为此过程的一部分，除非使用 azure 存在重大障碍，否则将不再允许从 appveyor 上传。我们最近升级了 azure 上的编译器基础设施，以支持此策略变更。

尽管我们进行了广泛的测试，但我们不希望此更改完全顺利，因此请耐心等待。与往常一样，如果您有任何问题、疑虑或麻烦，您可以在 Gitter 上找到我们，或直接在 Github 上联系我们！

我们将在两周后的 2020-04-07 正式弃用 vs2015，并将迁移到 vs2017。此更改将使我们能够在 Azure 上为 win 平台支持 msbuild 的使用，并将为 C++ 提供额外的支持。大多数使用 vs2015 构建的软件包都可以与 vs2017 工具链链接（但反之则不然）。一个例外是使用程序整体优化（/GL 标志）编译的静态库，它们可能与 vs2017 工具链不兼容。这些静态库将需要使用 vs2017 重新构建。

我们现在开始正式弃用 Appveyor，转而支持 Azure 以在 win 平台上进行构建。请注意，我们已经有一段时间没有向新的 feedstock 添加 appveyor 了，因此这不是一个完全新的策略变更。但是，现在我们将开始主动禁用不使用 Appveyor 的 feedstock 上的 Appveyor 构建，方法是关闭 GitHub push 事件的构建。此外，我们一直在向任何剩余的 feedstock 发布 PR，以将它们迁移到 Azure。我们意识到，某些使用 msbuild 构建的软件包尚无法迁移到 Azure，因此暂时为这些 feedstock 保留了 Appveyor。

webservices 管理员命令现在可用于将 Python 2.7 添加回 feedstock。在您的 feedstock 中的 issue 的标题中输入 @conda-forge-admin add python 2.7。然后，管理员 webservices 机器人将发布一个 PR，添加回 Python 2.7。请注意，此 PR 将删除其他 Python 构建以及任何 win、aarch64 或 ppc64le 构建。如果您想保留这些构建，请将 PR 合并到您的 feedstock 的单独分支中。

• 自 2020-01-01 起，上游开发人员不再支持 Python 2.7。因此，Conda-forge 正在弃用其 Python 2.7 支持。Conda-forge 将不为 Python 2.7 构建提供持续支持，并且任何现有构建均按“原样”提供。
• cf202003 标签已应用于 conda-forge 频道，以供需要引用带有 Python 2.7 的软件包索引的用户使用。
• 结合 Python 2.7 的弃用，我们正在移除对 Windows 上的 vs2008 的支持，因为它仅用于构建此版本的 Python。
• 我们将提供一个管理员命令，该命令将把 Python 2.7 添加回任何 feedstock。请注意，如上所述，我们无法为使用此管理员命令生成的任何 Python 2.7 构建提供支持。此外，此管理员命令仅适用于 osx-64 和 linux-64 平台。