我正在寻找一种表示变化程度的版本编号方案，尤其是兼容性。
例如，Apache APR使用众所周知的版本编号方案
<major>.<minor>.<patch>
example: 4.5.11
Maven提出了一个类似但更详细的架构：
<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732
Maven版本控制方案在哪里定义？是否有限定符和内部版本号的约定？可能使用maven但不遵循Maven版本方案是个坏主意...
您知道哪些其他版本编号方案？你更喜欢什么方案？为什么？
答案 0 :(得分：25)
以下是current Maven version comparison algorithm和discussion。只要版本只增长，并且除了内部版本号之外的所有字段都是手动更新的，那么你就是好的。限定符的工作方式如下：如果一个是另一个的前缀，则更长的时间更长。否则按字母顺序进行比较。将它们用于预发布。
借调语义版本控制来表达兼容性; major用于非向后兼容的更改，minor用于向后兼容的功能，patch用于向后兼容的错误修正。记录它，以便您的库用户可以正确地表达对库的依赖性。您的快照是自动执行的，除了发布后的第一个快照之外，不必增加这些快照，因为比较前缀的方式。
答案 1 :(得分：23)
我会推荐语义版本控制标准，Maven版本控制系统似乎也遵循该标准。请查看，
简而言之，它是<major>.<minor>.<patch><anything_else>，您可以为其他任何部分添加其他规则，因为这些规则似乎适合您。例如。 -<qualifier>-<build_number>。
答案 2 :(得分：6)
纯粹为了完整，我会提到old Apple standard for version numbers。这看起来像主要版本。 次要版本。 错误版本。 阶段。 非发布版本。 Stage是从集合 d （开发）， a （alpha）， b （beta）或 fc <中绘制的代码/ em>（最终客户发货 - 我认为或多或少与发布候选人相同）。
阶段和非发布版本仅用于缺少正确版本的版本。
因此，某些东西的第一个版本可能是1.0.0。您可能已经发布了1.0.1的错误修正，1.1版的新版本（具有更多功能），以及2.0的重写或主要升级。如果你想要向2.0.1工作，那么你可以从2.0.1d1,2.0.1d2开始，到2.0.1d153或者它花费的任何东西，然后发送2.0.1a1到QA，并在他们批准2.0.1a37之后，将2.0.1b1发送给一些愿意投注者，然后在场上一周内存活2.0.1b9后，烧掉2.0.1fc1并开始获得签收。当2.0.1fc17足够时，它将变为2.0.1，并且会有很多欢乐。
这种格式足够标准化，它有一个打包的二进制格式，以及库中的辅助例程进行比较。
答案 3 :(得分：4)
在阅读了很多文章/ QA /常见问题/书籍后，我开始思考 [MAJOR]。[MINOR]。[REV] 是最有用的版本控制架构 描述项目版本（版本控制架构）之间的兼容性 对于开发人员，不用于营销）。
MAJOR 更改向后不兼容，需要更改 项目名称，文件路径，GUID等。
MINOR 更改向后兼容。马克介绍新的 特征
REV 用于修复安全性/错误。向后和向前兼容。
此版本控制架构受 libtool 版本控制语义和文章的启发：
http://www106.pair.com/rhp/parallel.html
注意：我还建议提供构建/日期/自定义/质量作为附加信息（构建） 编号，构建日期，客户名称，发布质量）：
国家银行， 2011-05-03 ，测试版
但此信息不版本信息！
答案 4 :(得分：0)
请注意，版本号方案（如x.y.0与x.y）可能会受到外部因素的限制。
考虑announcement for Git 1.9 (Januaury 2014)：
发布候选人Git v1.9-rc2现在可以在通常的地方进行测试。
我听说有传言称各种第三方工具不喜欢两位数的版本号（例如＆＃34; Git 2.0＆＃34;）并开始当用户安装v1.9-rc1时左右bar 虽然很容易因为他们草率的假设而嘲笑他们，但我也很实际 不介意调用即将发布的版本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，具体取决于我们正在查看的功能跳转的大小。