Conan 1.34：新增 lockfile 功能“bundles”，资源转向 Conan v2.0，合并部落提案
Conan 1.34 带来了几个功能新增和少量 bug 修复。功能列表的简短并非由于缺乏努力或时间，而是反映了 Conan 团队的一个里程碑。这是第一个开发人员大部分时间和精力都花在 Conan 2.0 的重大更改上的发布周期，其中许多更改已经计划了数年。因此，本文将重点介绍目前正在构建的一些主要路线图项目。此外，值得注意的是，这其中包括来自 Conan 2.0 部落 的一项主要反馈，我们将在本文中进行讨论。
conan lock bundle
在讨论 Conan 2.0 之前，让我们简要总结一下此版本中新增的一项主要功能，即“lockfile bundle”（锁文件捆绑包）的概念。锁文件捆绑包旨在帮助 CI/构建工程师以更安全有效的方式处理锁文件集合。相关的命令可以通过运行以下命令找到：
注意：锁文件捆绑包和相关命令均为实验性功能。
以下是创建捆绑包的语法示例
conan lock bundle create app1_windows.lock app1_linux.lock app2_windows.lock
app2_linux.lock --bundle-out=lock.bundle
以下是一个图表，用于说明在“lock.bundle”文件中创建的数据结构。
锁捆绑包的概念旨在解决我们在企业代码库中大规模管理锁文件时发现的两个问题。
首先，它使 Conan 可以通过单个“构建”来更新多个锁文件，前提是这些锁文件共享一个公共依赖项以及该依赖项的 package_id。例如，在上图中，app1_windows.lock 和 app2_windows.lock 都依赖于 pkga/0.1 的相同 package_id。新的锁 bundle 使创建 CI 工作流成为可能，该工作流可以先构建一次该 package_id 的 pkga/0.1，并在完成后更新所有包含它的锁文件。
以下是用捆绑包重建 pkga 一次并更新两个锁文件的语法示例。
conan install pkga/1.0 --build pkga \
--lockfile app1_windows.lock \
--lockfile-out app1_windows.lock
conan lock bundle update lock.bundle
这样做的动机在于，拥有多个共享具有相同 package_id 的包的锁文件的情况非常普遍。自从发布锁文件以来，在 CI 中使用它们的典型方法是每个锁文件运行一次构建。但是，在这种情况下，当“每个锁文件”进行重建时，几乎总是会发生冗余重建，从而导致许多不同的可扩展性问题。有了“捆绑包”，CI 工程师现在可以配置作业以“每个包 ID”进行构建，并获得完全相同的好处，同时避免这些问题。
其次，“锁捆绑包”使能够为一组锁文件计算 build-order.json 文件。这对于 CI 工作流来说非常重要，因为 CI 作业通常会使用多个锁文件在一个“运行”中重建多个配置。在这些 CI 作业结束时，理想的最后一步是使用 Conan 生成一个 build-order.json 文件，以确定需要重建的下一个“包”，并将这些包映射到需要触发的 CI 作业。但是，以前 build-order.json 仅在“每个锁文件”的基础上生成，不同锁文件的构建顺序通常会产生不同的“下一步”。因此，使用此功能，我们现在可以生成一个考虑捆绑包中所有锁文件的“构建顺序”。这里最大的好处是它可以最大程度地并行化 CI 作业，并让 Conan 依赖项树驱动 CI 工作流过程。
资源转向 Conan V2
在过去的一个月里，Conan 团队已正式将大部分开发时间转向 V2。话虽如此，这可能也是设定一些期望值的好机会。请记住，目前计划用于 V2 的大多数重大更改和重构仍然“只是计划”。现在必须结合所有其他更改，对它们进行全面开发和测试。此外，其中许多需要反向移植到 Conan 1.x，以便在 Conan 1.x 和 2.x 之间存在安全的迁移路径。也就是说，这不仅仅是编写代码来添加功能的问题。它包括新的需求、新的概念、新的抽象以及大量的反复试验。尽管如此，我们计划保持积极性和专注性，直到完成为止。
Conan 2.0 跟踪
如果您想跟踪进度，甚至想贡献代码，以下链接可能是跟踪 Conan 2.0 总体进度的最佳链接。
https://github.com/conan-io/conan/pulls?q=is%3Apr+milestone%3A2.0+
以下是一些重点，对应于目前正在开展的一些最活跃的工作。
此列表中的“新的本地开发流程”是独一无二的。它代表了 Conan 的一项重大更改，该更改最初是在正式文档中描述的，并发送给 Conan 2.0 部落 以征求反馈。反馈意见总体上是支持的，但包括一个关于细节的重大更改的几乎一致的建议，该建议已被纳入最终的设计计划。这是部落取得高度成功的案例，也是其成立的根本原因。
同样，上面列出的 Conan 2.0 工作清单仅是目前正在积极开展的项目中的一部分。已经有相当数量的 pull 请求已合并，并且还有更多即将到来。我们几乎肯定会在未来的博客文章中更多地关注新 pull 请求的发布，因此请务必继续关注！
请记住，与 Conan 团队分享任何宝贵的见解或用例的最佳时机是昨天。但是，今天也是一个不错的时机，因此，如果您尚未提供反馈，请考虑联系我们并提供有关这些新功能和更改的反馈。
除了上面列出的项目之外，还有一长串可能值得您阅读的具有相当影响力的 bug 修复。如果是这样，请参阅 更改日志 以获取完整列表。
我们希望您喜欢此版本，并期待您 提供反馈。