我知道没有关于软件版本控制的固定规则，但我有几个问题。
1）如何正确升级版本
我有一个小软件，我刚开始使用，自从我从头开始，我开始使用0.1版本。
当我添加更多功能时，我一直在升级次要号码。现在我在v0.5.7（次要（.5）用于新功能和修订版（.7）进行错误修复和微小更改），事情是该程序几乎完成分发，但现在我“失踪” “几个小版本，你们如何处理这种情况？你只是跳过数字吗？
这让我想到了第二个问题。
2）哪个是好的起始版本号
我即将开始一个新项目。这个时间并不是一个小项目，并且将公开并且可以免费修改，我不希望遇到上述问题。那么这将是一个很好的起点呢？
奖金问题：
3）将数字设为10以上是否可以？比如v1.25或v2.2.30？
我没有看到带有这种编号的软件（可能只在帮助部分或他们的网页中显示），我再次意识到没有规则，但它似乎是那里是如何保留版本号的一般同意。
答案 0 :(得分：33)
版本控制策略有时可能有点疯狂（请参阅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。
请注意，“正确”（虽然在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（第N个为v1.9.N）;和- v1.9.0之后的功能版本将是v1.10.0或v2.0.0，具体取决于我们正在查看的功能跳转的大小。
2019年2月更新：semver本身即将发展（再次，在semver2之后）
请参阅“What’s next for SemVer”和semver/semver/CONTRIBUTING。
答案 1 :(得分：3)
在我们公司，我们使用四种令牌版本概念。它类似于 a.b.c.d 类：
(major).(feature).(revision).(bug/refactoring)
它与我们在开发生命周期中使用的问题类型有关。我们可以一目了然地跟踪两个以下版本之间已完成或已更改的内容。通过比较以下两个版本号，您可以确定所完成问题的数量和类型。 有关详细信息，请full documentation is here.
答案 2 :(得分：1)
即使我在使用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 - 代表更改 更改Numbe r：2 - 代表错误修正
虽然对于每个bugfix都可能会有代码更改，因此它代表默认的代码更改。但更具意义的是，您可以使用奇数来表示更改，甚至可以使用偶数来表示错误修正。
最后一部分是默认号码，谢天谢地.Net允许我们输入*来设置默认的内部版本号。它会随着每个编译/构建提供一个签名标记而不断增加，如果其他人重建它会发生变化。
如何实施：
打开Properties文件夹中的AssemblyInfo.cs并注释AssemblyFileVersion，这将使AssemblyFileVersion＆amp; 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 或其他什么
此方法的好处是您可以跟踪生成代码的任务。只需查看我可以说的版本号，＆＃34;嘿它是sprint 4的版本1，并且有一些代码更改。
答案 3 :(得分：0)
Semantic Versioning现在几乎是事实。
我“缺少”几个次要版本，你们如何处理这种情况？
您不会缺少版本。完全可以接受…（请参阅下一个答案）
哪个是很好的起始版本号
取决于人们是否在生产中使用您的代码。如果已在生产中使用，则直接跳至v1.0.0。但是，由于您说的代码质量为 alpha ， beta 或 rc （候选发布），但是您打算快速投入生产以v1.0.0-[alpha].N开头，其中[alpha]是软件等级，N是内部版本号或其他可枚举的值。
让数字大于10可以吗？例如v1.25或v2.2.30？
就是这个想法。字典式排序可能不起作用，但这没关系。