24

我一般同意程序的主要版本应该是1.0, 2.0, ... 并且重要更新应该是: 1.1, 1.2, ..., 并且错误修复应该是第三级: 1.0.1, 1.0.2, ... 1.0.156(如果你已经受到版本之间的许多错误修复版本的困扰）。

但现在我想发布我的第一个 Beta，这将是导致版本发布的一系列 Beta 之一1.0。

具体来说，对我来说，将我的 Beta 版本编号大于我正在开发的数量是没有意义的，例如1.0.1最多1.0.15（如果我有 15 个 beta 版本），然后用1.0.

但是使用小于的数字1.0似乎很尴尬，例如0.9.1...0.9.15如果我开始使用1.9.1...1.9.15作为 version 的 Beta会引起混乱2.0。

有关的：

版本号怎么做？

仅供参考，在您的帮助和与更多信息的良好链接之后，这就是我决定的。

对于我的 alpha 版本，我一直在 0.7、0.8、0.9、0.91 ... 到 0.98。

我知道我可以做 1.0 beta 1，这是“标准”方式。但考虑到所有因素，我将使用：0.99 beta 1、0.99 beta 2 ……在我发布 1.0 之前。

如果我对我的 2.0 版本进行预发布，我可能会遵循该模式并将其称为 1.99 beta 1、1.99 beta 2 等。

希望这个问题和答案能帮助您决定您的方案。

4

6 回答 6

25

我认为您应该将版本编号与发布状态分开。

Beta 版本后应始终带有“beta”。用户不必对您的编号方案进行逆向工程来确定版本的稳定性。

因此，在版本 1.0 之前，您应该拥有 1.0 beta 1、1.0 beta 2 等。这让用户可以更清楚地了解 beta 正在走向什么主要版本，并避免与您可能同时发布的任何维护版本混淆。

重要的是您需要区分错误修复版本（应该会增加稳定性）和测试版（可能会降低稳定性）。

于 2009-09-21T21:58:30.327 回答
5

如果您使用的是旧版本的Semantic Versioning（从2011-03-27 之前），则此部分是相关的：

可以通过紧跟补丁版本后附加任意字符串来表示特殊版本号。字符串必须仅由字母数字加上破折号 [0-9A-Za-z-] 组成，并且必须以字母字符 [A-Za-z] 开头。特殊版本满足但优先级低于相关的正常版本。优先级应由字典 ASCII 排序顺序确定。例如：1.0.0beta1 < 1.0.0beta2 < 1.0.0。

于 2011-01-25T08:53:36.197 回答
4

版本号完全由您决定。您可以在动物或城市名称之后调用它们或使用数字。

许多项目想知道如何处理下一代软件（2.0、3.0 等）的测试版编号

无论你做什么，只要记住你可以做任何你想做的事。因为版本号是营销的东西。仅供用户查看此版本在流程中的位置。

所以称它为 2.0 Beta 1、Beta 2 等会很好，也是最重要的。用户会理解的。

于 2009-09-21T21:23:25.723 回答
4

一个非常实用的解决方案是通过版本号命名您的测试迭代（例如 My Awesome App r1392）。

苹果、微软和许多其他公司这样做是为了他们的内部修订，并且只为推送给他们的客户的版本发布“真实”版本号。

于 2009-09-21T22:05:55.980 回答
1

我认为 beta 版本是对应用程序“第零”版本的小修改，因此 beta 1 将是0.1，beta 2 将是0.2.等等。

于 2009-09-21T20:21:24.910 回答
1

1.2.3 - 其中“1”是主要版本，不是 beta beta 是 1.0 之前的版本，“2”是主要版本，包括新功能，“3”是次要版本。如果你愿意，你可以在之后附加另一个，比如你的版本控制的提交 ID 或其他东西......但我回避了。

于 2009-09-21T20:24:19.053 回答