我知道没有关于软件版本控制的固定规则，但我有几个问题。
1）如何正确升级版本
我有一个小软件，我刚刚开始，因为我从头开始，我开始使用0.1版本。
随着我添加了更多功能，我一直在升级次要号码。现在我在v0.5.7（次要（.5）用于新功能和修订版（.7）进行错误修复和微小更改），事情是该程序几乎完成分发，但现在我“失踪” “几个小版本，你们如何处理这种情况？你只是跳过数字吗？
这让我想到了第二个问题。
2）哪个是好的起始版本号
我即将开始一个新项目。这个时间并不是一个小项目，并且将公开并且可以免费修改，我不希望遇到上述问题。那么这将是一个很好的起点？
奖金问题：
3）数字大于10可以吗？像v1.25或v2.2.30？
我没有看到带有这种编号的软件（可能只在帮助部分或他们的网页中显示它），再次我知道没有规则，但似乎有一般同意如何保留版本号。
版本控制策略有时可能有点疯狂（参见Version numbers and JSR277或Oracle及其Oracle Database 11g第2版：11.2.0.1.0。
另见Software Versioning is Ridiculous）。
但你可以先看看Eclipse Version Number policy作为一个好的开始。 如果你真的认为你需要三个以上的数字，这个V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation也很有趣，但更适用于1.0版本的软件，其中修订包和临时修复程序是有序的。
1 /“已经发货”：1.0.0
也被称为“1.oh-oh”版本。至少，它就在那里，您可以开始获得反馈并快速迭代。
2 / 0.x如果仍然缺少主要特征; 1.0.0，如果主要功能在那里。
3 /是的，但我想说的只是寿命超过几年的大型项目（通常是十年）
请注意，“正确”（虽然在Semantic Versioning 2.0.0中详细描述）也可以由更实用的因素指导：
见announcement for Git 1.9 (Januaury 2014)：
发布候选版Git v1.9-rc2现在可以在通常的地方进行测试。
我听说有传言说各种第三方工具都不喜欢两位数的版本号（例如“Git 2.0”），并且在用户安装v1.9-rc1时左右开始向左右移动。 虽然很容易因为他们草率的假设而嘲笑他们，但我也很实际，并且不介意调用即将发布的版本v1.9.0来帮助他们。
如果我们走那条路（此时我倾向于走这条路），版本控制方案将是：
- 下一个候选版本将是
v1.9.0-rc3，而不是v1.9-rc3;v1.9.0的第一个维护版本将是v1.9.1（和Nth one bev1.9.N）;和- v1.9.0之后的功能版本将是v1.10.0或v2.0.0，具体取决于我们正在查看的功能跳转的大小。
2019年2月更新：semver本身即将发展（再次，在semver2之后）。
参见“What’s next for SemVer”和semver/semver/CONTRIBUTING。
在我们公司，我们使用四种令牌版本概念。它类似于a.b.c.d类：
(major).(feature).(revision).(bug/refactoring)
它与我们在开发生命周期中使用的问题类型有关。我们可以一目了然地跟踪两个以下版本之间已完成或已更改的内容。通过比较以下两个版本号，您可以确定所完成问题的数量和类型。有关更多信息，请访问full documentation is here.
即使我在使用CRM开发时定义版本号时遇到了这个问题，因为我想在所有系统中部署相同的版本。我找到了一种方法来解决它与系统值+手动+ randoms。
程序集的版本信息由四个值组成：
主要版本。次要版本。内部编号。调整
这默认为初始版本1.0.0.0。为了更有意义，我用它替换它
TFS发布。 TFS Sprint。更改号码。增加的内部版本号
假设在你的TFS中，单个版本包含30个sprint，之后版本变为2，因此第一个版本的值将是：
TFS发布：1
如果当前冲刺是4，那么TFS Sprint将拥有
TFS Sprint：4
现在第三部分由开发人员管理，初始版本我们可以有0，每个ChangeRequest或BugFix可以增加+1。
更改编号：0 - 表示初始版本更改编号：1 - 表示更改更改编号：2 - 表示错误修复
虽然对于每个bugfix都可能会有代码更改，因此它代表默认的代码更改。但更具意义的是，您可以使用奇数表示更改，偶数表示错误修正。
最后一部分是默认数字，谢天谢地.Net允许我们将*放入默认的内部版本号。它会随着每个编译/构建提供一个签名标记而不断增加，如果其他人重建它会发生变化。
如何实施：
打开Properties文件夹中的AssemblyInfo.cs并注释AssemblyFileVersion，这将使AssemblyFileVersion和AssemblyVersion相同。
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.4.2.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
所以最终版本将出现：1.4.2.4512或其他什么
此方法的好处是您可以跟踪生成代码的任务。只需查看我可以说的版本号，“嘿，它是sprint 4的第1版，并且有一些代码更改。
Semantic Versioning现在非常事实上。
我“缺少”几个小版本，你们如何处理这种情况？
你不缺少版本。它完全可以接受......（见下一个答案）
这是一个很好的起始版本号
取决于人们是否在生产中使用您的代码。如果它已经在生产中使用直接跳到v1.0.0。但是，既然你说你的代码是alpha，beta或rc（候选版本）质量，但你计划快速转向生产，请考虑从v1.0.0-[alpha].N开始，其中[alpha]是软件等级，N是内部版本号或其他可枚举的值。
数字大于10可以吗？像v1.25或v2.2.30？
这就是主意。字典排序可能不起作用，但没关系。