代码版本更改“规则”[关闭]

我知道关于软件版本控制没有固定的规则，但我有几个问题。

1）如何正确升级版本

我有一个不久前开始使用的小软件，自从我从头开始以来，我从 0.1 版本开始。

当我添加更多功能时，我一直在升级次要版本号。现在我处于 v0.5.7（次要版本（.5）用于新功能，修订版（.7）用于错误修复和细微更改），问题是该程序几乎已完成分发，但现在我“缺少“几个小版本，你们遇到这种情况怎么处理？你只是简单地跳过数字吗？

这就引出了第二个问题。

2) 哪个是好的起始版本号

我即将开始一个新项目。这次的项目不小，而且是公开的，可以免费修改，我不想再出现上面提到的问题。那么哪个是一个好的起点呢？

奖金问题：

3) 数字可以大于10吗？比如 v1.25 或 v2.2.30？

我还没有看到具有这种编号的软件（可能他们只在帮助部分或他们的网页中显示它），我再次知道没有任何规则，但似乎有一个通用的同意如何保留版本号。

版本编号策略有时可能有点疯狂（请参阅版本号和 JSR277 http://alblue.bandlem.com/2008/05/version-numbers-and-jsr277.html, or Oracle http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html，及其 Oracle Database 11g 第 2 版：11.2.0.1.0.
也可以看看软件版本控制是荒谬的 http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/).

但你可以先看看Eclipse 版本号策略 http://wiki.eclipse.org/Version_Numbering作为一个好的开始。
如果你真的认为你需要超过三位数，这个V.R.M.F.维修流运输车术语解释 http://www-01.ibm.com/support/docview.wss?uid=swg27008656也很有趣，但对于 1.0 后的软件程序来说更是如此，其中修复包和临时修复是有序的。

1. 如何正确升级版本

“已经发货”：1.0.0

也被称为“1.oh-oh“版本。至少，它已经存在，您可以开始获取反馈并进行迭代fast.

2. 哪个是好的起始版本号

0.x if major功能仍然缺失；1.0.0如果有主要特征的话。

3. 数字大于10可以吗？比如 v1.25 或 v2.2.30？

是的，但我想说的只是生命周期超过几年（通常是十年）的大型项目

请注意“正确”（虽然在语义版本控制 2.0.0 http://semver.org/）也可以以更务实的因素为指导：

See the Git 1.9 公告（2014 年 1 月） https://lists.q42.co.uk/pipermail/git-announce/2014-January/000647.html:

候选版本 Git v1.9-rc2 现在可以在通常的地方进行测试。

我听说有传言说各种第三方工具不喜欢两位数的版本号（例如“Git 2.0”）并开始左右呕吐当用户安装 v1.9-rc1 时。
虽然人们很容易嘲笑他们草率的假设，但我也很务实， 不介意调用即将发布的 v1.9.0 来帮助他们。

如果我们走这条路（我现在倾向于走这条路），版本控制方案将是：

• 下一个候选版本将是v1.9.0-rc3, not v1.9-rc3;
• 第一个维护版本v1.9.0将v1.9.1（第 N 个是v1.9.N); and
• v1.9.0 之后的功能版本将是 v1.10.0 或 v2.0.0，具体取决于我们期望的功能跳跃有多大。

2019 年 2 月更新：semver 本身即将演变（同样是在 semver2 之后）。
See "SemVer 的下一步是什么 https://words.steveklabnik.com/what-s-next-for-semver#fnref2", and semver/semver/CONTRIBUTING https://github.com/semver/semver/blob/master/CONTRIBUTING.md.