cargo-dist-schema

cargo-dist 的 dist-manifest.json 的模式报告/解析，这是在运行 --output-format=json 时从 cargo dist build 或 cargo dist plan 命令时得到的输出。

请在此处阅读我们的文档！

这可以用于解析 cargo-dist 生成的机器可读清单。理想情况下，它应该与清单的新旧版本兼容。

这种兼容性非常重要，因为一个工具可能需要查看分散在 多年 的发布。另外，cargo-dist 从之前的版本开始自我托管，因此当查看 cargo-dist 的自身发布时，清单和描述清单的工具中总会存在至少一个偏移量。

目前有 3 个 dist-manifest.json 的时代

• 时代 1 <= 0.0.2
• 0.0.3-prerelease9 <= 时代 2 <= 0.0.6-prerelease.6
• 0.0.3-prerelease.8 <= 时代 3

时代 1 是初步实验，现已不再支持。

在第2个纪元，我们对设计的约束有了更好的理解后，做了一些重大变更。最显著的变更是将一些对象拉入顶级Object，并通过键直接引用，这样不同的发布版本就可以共享一个工件（例如共享二进制文件的debuginfo/symbol文件）。这使得纪元1和2之间的版本差距变得模糊，使用cargo-dist的预发布版本并不推荐。我们认为0.0.3-prerelease9是事情稳定下来的地方，应该与0.0.3正式版本相同。

第3个纪元具有相同的格式，但我们从工件ID名称中删除了版本号，改变了URL的格式。这主要影响cargo-dist自行获取的能力，并创建了一个临时的发布版本（0.0.6-prerelease.7），因为它使用了epoch2版本（0.0.5），所以无法自行获取。这个版本故意没有在crates.io上发布。CI已手动更新，以使用正确的URL来引导0.0.6-prerelease.8，它是完全在epoch3中的。

关于自托管/引导的简要说明

cargo-dist的CI使用之前的发布版本进行自托管。表面上似乎有一个连贯的发布版本引导链，但在纪元边界附近，事情变得有些奇怪。您始终可以使用cargo build直接从源代码构建，所以这并不是一个大问题。

但为了我自己学习

• v0.0.1-prerelease1是第一个未发布版本，使用临时副本构建
• v0.0.1-prerelease2将是第一个发布版本，使用0.0.1-prerelease1构建
• v0.0.1将是第一个从另一个发布版本构建的版本

尴尬的是，如果我们想让cargo-dist的发布版本包含其自身的新特性，我们需要为该特性创建中间的预发布版本，以便“追赶”。因此，稳定版本基本上永远不是从上一个稳定版本构建的。https://github.com/axodotdev/cargo-dist/commit/8a417f239ef8f8e3ab66c46cf7c3d26afaba1c87