如何区分测试版和普通版？
我通常同意程序的主要版本应该是 1.0、2.0...，重要更新应该是：1.1、1.2，...，错误修复应该在第三级：1.0.1，1.0.2，... 1.0 .156（如果您一直被版本之间的许多错误修复版本所困扰）。
但现在我想发布我的第一个 Beta，这将是导致 1.0 版本发布的一系列 Beta 之一。
具体来说，将我的 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 的测试版。
有关的：
仅供参考，在您的帮助和更多信息的链接之后信息，这就是我的决定。
我的 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 等。
希望这个问题和答案将帮助您决定您的方案。
I generally agree that major versions of a program should be 1.0, 2.0, ... and significant updates should be: 1.1, 1.2, ..., and that bug fixes should be at the third level: 1.0.1, 1.0.2, ... 1.0.156 (if you've been plagued by that many bug-fix releases between versions).
But now I want to release my first Beta that will be one of a series of Betas leading towards the release of version 1.0.
Specifically, it doesn't make sense to me, to number my Beta releases greater than the number I am developing to, e.g. 1.0.1 up to 1.0.15 (if I have 15 beta releases) and then follow it with 1.0.
But using numbers less than 1.0 seems awkward, e.g. 0.9.1 ... 0.9.15 and will cause confusion if I start using 1.9.1 ... 1.9.15 as the Betas for version 2.0.
Related:
Just for information, after your help and great links with more info, this is what I decided on.
I've been going 0.7, 0.8, 0.9, 0.91 ... up to 0.98 for my alpha versions.
I know I can do 1.0 beta 1, which is the "standard" way. But taking everything into account, I'm going to go with: 0.99 beta 1, 0.99 beta 2 ... before I get to my 1.0 release.
If I do a pre-release of my 2.0 version, I'll probably then follow the pattern and call it 1.99 beta 1, 1.99 beta 2, etc.
Hopefully this question and the answers will help you decide on your scheme.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一种非常实用的解决方案是通过版本号命名您的测试迭代（例如 My Awesome App r1392）。
苹果、微软和许多其他公司都在内部修订中这样做，并且只为推送给客户的版本发布“真实”版本号。
One very practical solution is naming your testing iterations by release numbers (e.g. My Awesome App r1392).
Apple, Microsoft and many others do this for their internal revisions and only issue "real" version numbers for version pushed to their customers.
我认为 beta 版本是应用程序“第零”版本的小修改，因此 beta 1 将为
0.1，beta 2 将为0.2。等等。I would consider beta releases to be minor revisions to the "zero'th" version of the application so beta 1 would be
0.1, beta 2 would be0.2.and so on.1.2.3 - 其中“1”是主要版本发布，而不是 beta beta 是 1.0 之前的版本，“2”是包括新功能的主要版本，“3”是次要版本。如果你愿意，你可以在之后附加另一个，就像你的版本控制的提交 ID 或其他东西......但我回避这一点。
1.2.3 - Where "1" is major version releases, not beta beta would be pre 1.0, the "2" would be major releases including new features, the "3" is minor releases. If you like you can append another after that that can be like your version control's commit id or something... but i shy away from that.
我认为您应该将版本编号与发布状态分开。
Beta 版本后应始终带有“beta”。用户不必对编号方案进行逆向工程来确定版本的稳定性。
因此，在版本 1.0 之前，您应该拥有 1.0 beta 1、1.0 beta 2 等。这可以让用户更清楚地了解 Beta 版将走向哪个主要版本，并避免与您同时发布的任何维护版本混淆。
重要的是，您需要区分错误修复版本（这应该会提高稳定性）和测试版（这可能会降低稳定性）。
I think you should seperate out your version numbering from the status of the release.
Betas should always have "beta" after the version. Users should not have to reverse engineer your numbering scheme to determine the stability of the release.
So leading up to version 1.0 you should have 1.0 beta 1, 1.0 beta 2 etc. That gives users a clearer idea of what major release a beta is leading towards and avoids confusion with any maintainance releases you might put out in the meantime.
The important thing is that you need to distiguish between a bugfix release (which should increase stability) and a beta (which may decrease stability).
如果您使用语义版本控制，（来自 2011-03-27 之前），此部分是相关的：
If you're using an old version of Semantic Versioning, (from before 2011-03-27), this section is relevant:
版本号完全取决于您。您可以用动物或城市名称或数字来称呼它们。
许多项目想知道如何处理下一代软件（2.0、3.0 等）的测试版数字，
无论您做什么，只要记住您可以做任何您想做的事情。因为版本号是一种营销手段。只是为了让用户看到这个版本处于流程的哪个阶段。
因此，将其称为 2.0 Beta 1、Beta 2 等就可以了，而且是最重要的。用户会理解的。
Version numbers are totally up to you. You could call them after animals or city names or use numbers.
Many projects wonder what to do with beta numbers for next gen software (2.0, 3.0 etc)
And whatever you do, just remember that you can do whatever you want to. Since version numbers are a marketing thing. It's just for users to see where in the process this version is.
So calling it 2.0 Beta 1, Beta 2 etc would work fine and the most important thing. The users would understand.