我普遍同意程序的主要版本应为1.0，2.0，...并且重要更新应为：1.1，1.2，... ，并且错误修复应该在第三级：1.0.1，1.0.2，... 1.0.156（如果您一直受到版本之间的许多错误修复版本的困扰）。
但现在我想发布我的第一个测试版，它将成为导致版本1.0发布的一系列Betas之一。
具体来说，对我来说，将我的Beta版本编号大于我正在开发的编号，例如，对我来说没有意义。 1.0.1最多1.0.15（如果我有15个测试版），然后使用1.0关注它。
但使用小于1.0的数字似乎很尴尬，例如0.9.1 ... 0.9.15如果我开始使用1.9.1 ... 1.9.15作为版本2.0的Betas，将会造成混淆。
仅供参考，在您的帮助和更多信息的链接之后，这就是我决定的。
我的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等。
希望这个问题和答案可以帮助您确定您的计划。
答案 0 :(得分：17)
我认为您应该从发布状态中分离出您的版本号。
Betas应该在版本之后始终拥有“beta”。用户不必对编号方案进行反向工程，以确定发布的稳定性。
因此，在版本1.0之前，您应该拥有1.0 beta 1,1.0 beta 2等。这样可以让用户更清楚地了解测试版的主要版本，并避免与您在此期间发布的任何维护版本混淆
重要的是你需要在错误修复版本（应该增加稳定性）和beta版本（可能会降低稳定性）之间进行区分。
答案 1 :(得分：5)
如果您使用an old version的Semantic Versioning，（来自before 2011-03-27），则此部分相关：
特殊版本号可以是 表示为附加任意 紧跟在补丁之后的字符串 版。字符串必须包含在内 只有字母数字加上短划线 [0-9A-Za-z-]并且必须以a开头 字母字符[A-Za-z]。特别 版本满足，但有较低的 优先级高于相关的正常值 版。优先权应该是 由词典ASCII排序确定 订购。例如：1.0.0beta1＆lt; 1.0.0beta2＆lt; 1.0.0。
答案 2 :(得分：4)
一个非常实用的解决方案是按版本号命名测试迭代（例如My Awesome App r1392）。
Apple，Microsoft和其他许多人这样做是为了进行内部修订，只发布推送给客户的版本的“真实”版本号。
答案 3 :(得分：3)
版本号完全取决于您。您可以在动物或城市名称之后打电话给他们或使用数字。
许多项目都想知道如何处理下一代软件的测试数据（2.0,3.0等）
无论你做什么，只要记住你可以做任何你想做的事。由于版本号是一个营销的东西。这只是让用户看到这个版本在这个过程中的位置。
所以称之为2.0 Beta 1，Beta 2等可以正常工作，也是最重要的事情。用户会理解。
答案 4 :(得分：1)
我认为beta版本是对应用程序“零”版本的次要修订，因此beta 1将为0.1，beta 2将为0.2.，依此类推。
答案 5 :(得分：1)
1.2.3 - 如果“1”是主要版本发布，不是beta beta将是1.0之前，“2”将是主要版本，包括新功能，“3”是次要版本。如果你喜欢，你可以在那之后添加另一个，就像你的版本控制的提交ID或者其他东西......但是我回避它。