Release cycle zh CN
ASF 使用常见的 4 数字 C# 版本号，形式为 A.B.C.D。 给定的版本总是冻结的，指向其构建时的固定源代码（与二进制包一同发布）。 只要我们的托管服务商（GitHub）仍能很好地无限期保留它们，我们就不打算移除之前发布的任何版本，因此您可以安全地回滚到任何版本，而无需自行保留备份。
一般地，就 ASF 版本来说，我们会尽力在最后 3 个数字——B.C.D 上遵循 主版本号.次版本号.修订 形式的 semver（语义化版本）。 这三个数字直接与 ASF 代码相关。 最重要的 A 数字表示超出 ASF 代码本身范围的变化，通常直接影响程序的基本架构。
ASF 的项目目标是大约每月发布一个功能版本，以更新 C 数字来表示。 为了能够使用这种发布方式，我们为进阶用户提供较小的预览版本，如果自上次预览版之时有足够的变更，就会根据需要作为较小的里程碑发布为预览版。 最后，如果一个最新预览版被确定为足够稳定和成熟，与上个稳定版相比没有任何已知的关键回退需要修复，它就会被选为新的稳定版，同时为下一个版本开启月度周期。
我们会尽力保证即使是预览版本也是相对稳定的，但仍需注意在任何生产环境使用预览版时，需要仔细评估。 预览版可能含有严重错误或其他功能问题，这也是我们发布预览版的原因——避免稳定版出现这些问题，并提供可靠的软件。 如果您不打算接受使用不稳定软件带来的高风险，请不要使用我们的预览版构建，而应该始终使用适合大多数用户的稳定版。
根据周期中的变更数量，通常自上一个稳定版开始只会有一个 C 版本更新，并且每个预览版都会按需更新 D 版本。 然而，当引入更大范围内的变更（特别是破坏性变更）时，发布周期可能会开始自（或切换至） B 或 A 版本更新——这种切换表示当前的发布周期可能比平时更不稳定，应加以认真测试。 请注意，我们作出的语义化版本变更仅与之前发布的稳定版相关，我们不会跟踪一个周期内各个预览版之间的变化，例如，1.0.1.2 版本可能会引入 1.0.1.1 中不存在的新功能，只要上一个稳定版是来自于 1.0.0 系列。 同样地，同一个周期中的两个预览版之间也可以有重大的破坏性变更，当我们仍在决定新功能的最终形式时，情况尤其如此。
| 版本号更新 | 语义化版本 | 变更示例 |
|---|---|---|
| A | 重大 .NET 运行时变更、基础架构变更、超出 ASF 代码范围的破坏性变更、可能吃掉您的猫的功能 | |
| B | 主版本号 | 较小的 .NET 运行时变更、ASF 代码破坏性变更、超出次要变更的代码编辑 |
| C | 次版本号 | 新的月度周期，通常引入新功能、命令、配置属性或者其他不会破坏现有设置的变更 |
| D | 修订 | 当前发布周期（以更关键的版本数字表示）内的新预览版、不引入超出必要范围代码修改且针对当前稳定版的关键错误修复 |
请注意，新引入的功能和更改可能不会立刻被记录（例如在 Wiki 上），因为我们通常会在给定功能的代码编写完成的时候才编写文档（以便于我们在修改功能时节省编写文档的时间）。 由于预览版可能会包含未完成的代码，因此这些功能的文档可能要在之后的开发阶段中编写。 更新日志也是同样的，一些预览版的更新日志有时是不完整的。 因此，如果您决定使用预览版，就可能需要时刻关注 ASF 内部的提交。 当然，只有预览版才可能缺少文档说明——每个稳定版在发布时一定已有完整的更新日志和 Wiki 文档。
两个版本之间的详细更新日志总是可以在 GitHub 上比较——通过提交记录和代码变更。 在发布中，我们倾向于仅记录我们认为的上次稳定版与当前版本之间的重要更改。 这样的简短更新日志并不完整，所以如果您希望了解两个版本之间发生的详细更改（例如我们的依赖升级）——请查看 GitHub 比较。
ASF 项目由 CI 流程提供支持。 每个构建都应该是可重现的，因此如果您获取对应版本的源代码（在发布页面同时提供）并自行编译，其结果应该与我们预编译的二进制文件相同。 只要系统还能正常工作，我们通常避免自行编译发布，已发布的二进制包都直接来自于 CI 流程。
