更新版本真正意味着什么？

许多软件更新都遵循从v0.1到v0.2到v2.6.5.6的方案。这些对软件的“更新”到底意味着什么？是否始终遵循行业标准，还是程序员几乎一直在提高更新＃或添加更多小数？

就像肖恩所说的那样，实际上并没有一个标准。一些公司比其他公司具有更好的版本控制做法（我已经与跳过主要版本号的供应商打交道，而另一些公司则在以后的几个版本中使用相同的xy）。

话虽这么说，Gravatars的发明者和GitHub的共同创始人（Tom Preston-Werner）编写了“ 语义版本控制 ” 文档，值得一读。

这是简介的除外：

作为此问题的解决方案，我提出了一组简单的规则和要求，这些规则和要求规定了如何分配和递增版本号。为了使该系统正常工作，您首先需要声明一个公共API。这可能包含文档或由代码本身强制执行。无论如何，此API必须清晰准确。识别公共API后，您将以版本号的特定增量传达对它的更改。考虑XYZ的版本格式（Major.Minor.Patch）。不影响API的错误修复程序会增加补丁程序版本，向后兼容的API添加/更改会向后增加次要版本，向后不兼容的API更改会导致主版本。

我将此系统称为“语义版本控制”。在这种方案下，版本号及其更改方式传达了有关底层代码以及从一个版本修改到另一个版本的含义。

用4位数字表示，通常是MajorV.MinorV.PatchNum.BuildNum，至少在我工作的地方。

我个人更喜欢Ubuntu的版本控制方案-使生活变得更加轻松。

简短的版本是没有标准，公司可以按照自己的意愿做。本质上，您拥有的数字越多，每个数字代表的更改量就越小。通常，您至少会看到版本xy，其中xa中xa的变化表示主要发行版本（主要增强功能/功能推出），而y表示次要发行版本（重要调整或缺陷修复）。这两个小数点后的小数点对公司内部可能有不同的含义，尽管通常围绕较小的内容构建或补丁来表示更快，更小的修复。

维基百科上有一篇文章详细介绍了这一点。

版本号的目的是为问题报告提供参考。唯一的要求是每个发行版都有唯一的版本号。有些数字是由行销驱动的-更大的整数更容易出售，而幂数（例如10（罗马数字X））确实很吸引人。有些人使用语义版本控制的一些变体：

主要，小型，微型

• 主要增量：不兼容的更改或UI的完全重新设计
• 次要增量：已添加新功能，与具有相同主要版本号的先前版本兼容
• 微增量：错误修复版本
• 内部版本号：由编译器生成或从版本控制中提取

许多组在其发行版中删除了BUILD号。通常仅在测试和开发小组之间有用。

一些小组添加了其他语义，例如，奇数编号的MINOR增量用于实验版本，偶数编号的MINOR增量用于生产版本（Linux内核使用此方法）。

底线是没有标准，除了较新的版本使用更高的版本号，而且每个版本号都是唯一的。