12.5 测试版本

当你发布一个程序重大修改的新主版本时，你可能希望将其作为预测试版本发布。这意味着你创建一个 tar 文件，但只将其发送给你招募的一组志愿者。（使用合适的 GNU 邮件列表/新闻组来招募他们。）

我们通常使用服务器 alpha.gnu.org 来进行预测试和预发布版本。有关将新版本放置在 alpha.gnu.org 上的程序细节，请参阅自动 FTP 上传。

一旦一个程序被广泛使用并且人们期望它能稳定工作，那么在每个“真正”发布之前进行预测试版本发布是一个好主意。

有三种处理预测试版本号的方法。一种方法是将它们视为即将发布的版本之前的版本。

在这种方法中，如果你即将发布 4.6 版本，但想先进行预测试，则将其称为 4.5.90。 如果你需要第二次预测试，则将其称为 4.5.91，依此类推。 如果你真的不幸，十次预测试都不够，在 4.5.99 之后，你可以进阶到 4.5.990，依此类推。（你也可以使用 4.5.100，但 990 的优点是可以按正确的顺序排序。）

另一种方法是将日期附加到即将发布的版本号上。 例如，在 2002 年 12 月 10 日制作的 4.6 版本的预测试版本，将为 4.6.20021210。 同一天进行的第二次预测试版本可能是 4.6.20021210.1。

对于非正式预测试的开发快照，仅使用日期而不使用版本号也是可以的。

第三种方法，如果软件包使用 Git，则运行来自 Gnulib 的脚本 build-aux/git-version-gen 来生成测试版本号。 它生成的版本号格式为‘版本.提交次数-提交哈希’，其中 版本 是最新的版本标签，提交次数 是自该标签以来的提交次数，提交哈希 是最新提交的哈希代码。

你应该永远不要做的一件事是，以与计划的正式发布相同的版本号发布预测试版本。许多人只会查看版本号（在 tar 文件名中，在它解压缩到的目录名中，或在他们可以找到它的任何地方）来确定 tar 文件是否是最新版本。人们可能会以这种方式查看测试版本，并将其误认为是正式版本。因此，当你发布更改的代码时，请务必更改版本号。