Release cycle zh CN
ASF 使用 A.B.C.D 形式的常用 C# 版本号。每当向 GitHub 发布新版本时，版本号就会增加。 到目前为止发布的每个版本都可以在 GitHub 上获得，它们总是保持发布时的状态，并且不会随着时间消失，因此用户总是可以回滚到其中任何一个版本，而无需复制一份。
一般来说，ASF 的版本控制非常简单——我们将 0 到 9 之间的数字填入 A、B、C 和 D，每次升级将会使 D 增加 1，一旦 D 满 10，就增加 C 并将 D 重设为 0。 新版本的发布应被视为 ASF 的里程碑，即一个实现了特定功能并准备好进行测试/使用的版本，同时不会导致与以前版本相比出现任何倒退。 有时候我们可能会认为引入的变化非常重要，会直接增加 C、B 甚至 A 的数值，尽管这种情况非常罕见（并且通常说明存在一些重大变化）。
ASF 的版本分为两类——稳定版（Stable）和预览版（Pre-Release）。
与之前的版本相比，稳定版应该正常工作，没有任何已知的倒退（在发布时）。 我们会在较长时间的预览版测试之后发布稳定版，或者将稳定版作为修复上一个稳定版漏洞（并且不会引入新漏洞）的版本。 在极少数情况下（例如 Steam 发生重大变化），如果需要，我们也可能决定尽快发布新的稳定版本。 一般而言，这些版本应该非常适合平常使用，因为如果与先前的稳定版相比更不稳定，我们不会将此版本标记为稳定版。 当然，这种“稳定程度”是基于我们在发布前开发过程中收到的报告和反馈，遗憾的是，仍有可能一些错误会漏网，并在稳定版发布后被发现，因为没有人在开发阶段遇到此问题。 但事实上很少发生这种情况，并且即使出现，我们也会尽快发布一个新的稳定版修复。
预览版发布得更频繁，通常还会引入未完成的改变、建议或新实现。 我们不保证预览版是稳定的，但我们总是尝试在将它推送到 GitHub 之前做一些裸测试，因此预览版在实际使用方面通常不至于完全不可用。 预览版的主要目标是从高级用户那里获得反馈，并在发布稳定版之前找到新出现的漏洞（如果有的话）。 这项工作的质量很大程度上取决于测试人员的数量、GitHub 漏洞报告的数量和一般反馈的数量。
预览版版通常应该与稳定版一样好，这两者之间的唯一区别就是稳定版经过更多用户测试。 这是因为 ASF 是一个滚动项目，这意味着它应该可以在任何给定的时间点构建和使用，并且版本控制只是为了方便——作为两个版本之间变化的里程碑。 不过，如果您决定使用预览版，通常应该是更高级的用户，因为预览版通常是正在开发的较小的 ASF 里程碑，很可能即使有些功能看起来正常，但仍有可能有问题或者未通过测试——如果您仍要使用预览版，至少应该为了自己的利益，关注 ASF 在 GitHub 上的开发进程，并仔细阅读版本更新日志。 除此之外，有时我们会主动测试特定的内容，例如配置文件变更、代码重构或者核心功能的变化。 在这种情况下，您应该经常阅读更新日志，因为这样的预览版可能比其他版本更不稳定。
请注意，新引入的功能和更改可能不会立刻被记录（例如在 Wiki 上），因为我们通常会在给定功能的代码编写完成的时候才编写文档（以便于我们在修改功能时节省编写文档的时间）。 由于预览版可能会包含未完成的代码，因此这些功能的文档需要在之后的开发阶段中编写。 更新日志也是同样的，一些预览版的更新日志有时是不完整的。 因此，如果您决定使用预览版，就可能需要时刻关注 ASF 内部的提交。
当然，只有预览版才可能缺少文档说明——每个稳定版在发布时一定已有完整的更新日志和 Wiki 文档。
一个预览版可能会在一段时间之后被视为稳定版。 如果在这期间没有任何更改，并且没有必要仅仅为了发布稳定版而更改版本号，就会发生这种情况。 当预览版被视为“候选稳定版”时，也会发生这种情况，高级用户可以在它成为稳定版之前进行测试，此时引入漏洞的可能要低得多，因此 ASF 的版本经常符合这样的形式：
稳定版 1.0 -> 预览版 1.1 -> 预览版 1.2 -> ... -> 预览版 1.7（候选） -> 稳定版 1.7（与预览版 1.7 相同）
不过，通常情况下，ASF 版本会在准备就绪时发布，这可能导致不可预测的版本发布计划。 通常，在任何主要功能更新结束时会有一个预览版，如果预览版发布一段时间（几天）后没有发现漏洞，则发布一个稳定版。 我们的目标是大约每个月发布一个稳定版，除非有一些关键问题需要处理或者特殊情况。 当我们认为自上个版本以来，有足够多的内容需要测试时，就会发布一个预览版。 取决于当时 ASF 的开发强度，每两个稳定版之间可能会有几个到十几个预览版。
两个版本之间的详细更新日志总是可以在 GitHub 上比较——通过提交记录和代码变更。 在发布中，我们倾向于仅记录我们认为的上次稳定版与当前版本之间的重要更改。 这样的简短更新日志并不完整，所以如果您希望了解两个版本之间发生的详细更改——请通过 GitHub 实现。
ASF 工程由持续集成（CI）进程支持，并由两个独立的服务测试——AppVeyor 会在 Windows 上测试 ASF，而 Travis 将在 Linux 和 OS X 上测试 ASF。每次构建都应该是可重现的，因此如果您使用给定版本的源代码自行编译，应该与下载预编译二进制文件的结果相同。
此外，除了 ASF 稳定版和预览版，您也可以在这里找到最新的自动化 AppVeyor 构建，通常这是由最新的提交构建而来，并不属于任何版本。 由于自动化以及未经测试，这些构建完全不被支持，通常仅适用于需要获取最新 GitHub 快照的开发者，使他们不需要自己编译。 我们无法保证 master 分支中的 ASF 能够正常工作。 在极少数情况下，这些构建也可以用来验证尚未发布的提交是否确实修复了特定的问题或漏洞，而无需等待预览版的测试。 如果您决定使用这些自动构建，请确保您在 ASF 方面具有相当的知识，因为它们是漏洞最多的软件。 除非您有充分的理由，否则使用预览版构建已经足够抢先——AppVeyor 构建比预览版更甚，仅仅用来验证特定的提交是否修复了我们正在解决的问题。 这些构建不应该在任何生产环境中使用。
