Swift Package Index

在找到符合您需求的软件包后，您首先需要得到解答的问题是什么？

“这个软件包是否适用于我的应用程序所使用的 Swift 版本和平台？”

当我们最初发布 Swift Package Index 时，我们尝试使用软件包清单中可用的元数据来回答这个问题。即 swiftLanguageVersions 和 platforms 属性。

问题在于，这两个属性都不完美。swiftLanguageVersions 不够细化，官方仅允许 v4、v4_2 和 v5 值。platforms 属性稍好一些，但不允许软件包作者声明与非 Apple 操作系统（如 Linux）的兼容性。

如果您可以看到每个软件包都像这样的矩阵，那不是太棒了吗？😍

看看这个矩阵的信息量有多大。您可以立即看到 PromiseKit 的最新稳定版本与从 4.2 开始的每个 Swift 版本以及包括 Linux 在内的每个平台兼容。然后，您可以看到正在开发的 alpha 版本放弃了对 iOS、tvOS 和 watchOS 以及 Swift 4.2 的支持。这看起来很可疑，对吧？继续看，您会发现默认分支修复了所有这些问题并恢复了兼容性。我从这个矩阵中确信，当 7.0.0 发布时，它将在所有方面都打上绿色勾号，但我也知道不要依赖当前的 alpha 版本。这是实用且可操作的信息。

当我们开始思考如何最好地解决这个问题时，最明显的最佳解决方案是构建软件包！有什么比使用 Xcode 10.1 附带的 xcodebuild 版本构建软件包来查看软件包是否与 Swift 4.2 兼容更好的方法呢？

所以这就是我们所做的，它现在可用了。为什么不试用一下，搜索一些您最喜欢的软件包呢？🚀

准确、真实的兼容性数据

然而，这比“仅仅构建每个软件包”要复杂一些。一个软件包可能在 iOS 上使用 Swift 5.2 构建成功，但由于 UIKit 依赖项或其他 macOS 特定问题，相同的构建可能在 macOS 上使用 Swift 5.2 构建失败。需要的是一个构建矩阵，以生成兼容性的准确图景。

因此，如果我们在 iOS、macOS、tvOS、watchOS 和 Linux 上使用 Swift 5.1 运行构建，并且任何一个构建通过，则它与 Swift 5.2 兼容。如果任何 Swift 版本在 iOS 上构建成功而没有失败，则该软件包支持 iOS。

我们最终得到了一个平台列表，其中包括

• 使用 xcodebuild 的 iOS
• 使用 xcodebuild 的 macOS
• 使用 swift build 的 macOS (在某些情况下 swift build 会通过，而 xcodebuild 可能会失败，这是有充分理由的)
• 在 Apple Silicon 上使用 xcodebuild 的 macOS (是的，使用 DTK 编译！)
• 在 Apple Silicon 上使用 swift build 的 macOS
• 使用 xcodebuild 的 tvOS
• 使用 xcodebuild 的 watchOS
• 使用 swift build 的 Linux

然后我们决定了一个我们想要检查兼容性的 Swift 编译器版本列表

• Swift 4.2 (4.2.1)
• Swift 5.0 (5.0.1)
• Swift 5.1 (5.1.3)
• Swift 5.2 (5.2.4)
• Swift 5.3 (beta)

这每个软件包最多需要 32 个构建，但这仅仅是个开始。如果有一个稳定版本和一个 beta 版本呢？稳定版本可能支持 Swift 4.2 及更高版本，而新的 beta 版本可能会放弃对 Swift 5.2 以下任何版本的支持。这是选择软件包时很重要的信息，因此我们需要展示它。由于我们还跟踪默认分支的状态，因此我们也必须构建它，并且我们很快就到了可能需要每个软件包运行 96 个构建的地步！索引中几乎有 3,200 个软件包，这可能超过 300,000 个构建！😅

实际上，由于大多数软件包没有当前的 beta 版本，因此构建次数少于这个数字，但仍然是很多构建。在我写这篇文章时，我们已经处理了超过 200,000 个构建，而且我们还没有完全完成。截至今天，我们已经完成了 99%，所以我们几乎在发布之前完成了！😬

如果您一直在关注这些推文，那么所有这些处理是做什么的应该很明显了！让我们看一下我们生产服务器（一台配备 32Gb RAM 和 6 核 i7 CPU 的 2018 Mac mini）过去 30 天的 CPU 图表

您可以在该图中看到我们的一些最终测试运行，然后我们开始真正进行处理。从那时起，我们已经让 CPU 完全满负荷运行了两个多星期。我们还有我们的暂存 Mac mini、一台备用的 2016 MacBook Pro 和一台 DTK 也参与构建。

每个人都喜欢徽章

在本网站上提供兼容性信息是一回事，但每个人都喜欢用 shields.io 徽章装饰他们的软件包页面，不是吗？如果您维护一个开源项目，您不想在您的 README 文件中展示真实的兼容性状态吗，就像这样？

如果您是软件包作者，请单击每个兼容性矩阵下方的“复制徽章”按钮，您的剪贴板中将有一个 Markdown 图像链接，随时可以使用。

您的用户将始终看到实时的、准确的兼容性信息，这些信息会在您发布新版本时更新。

功劳归功于应得之人！

首先，我们要感谢我们在 MacStadium 的好朋友，感谢他们作为其 开源计划的一部分，为本项目提供了重要的托管资源。有一段时间，我们有点担心我们可能会熔化他们的机器，我们非常高兴我们没有。他们的表现非常出色。

我们还要感谢 Apple 的 Ankit Aggarwal 和 Boris Bügling。他们在 SwiftPM Slack 上的不懈帮助和支持为我们节省了无数小时来弄清楚解决这个问题的正确方法。

最后，我们想感谢在构建此功能的过程中提供帮助和反馈的每个人。没有你们中的任何一位，我们都无法做到这一点。

总结

一些软件包作者为他们的软件包设置了持续集成，当然，这包括一个构建步骤。但这通常只涵盖一个 Swift 版本，并且信息被隐藏在每个 repo 的不同位置。我们认为，通过集中这些数据并使其可用于所有软件包，我们应该能够帮助这个社区更好地决定他们的依赖项，而这正是本网站的宗旨。

我们希望您像我们一样喜欢这个功能！❤️