虽然经常听说更新版本、更新版本，但不知道版本号的具体使用规则，特意调查了maven中的版本控制。
官方说明
语义化版本控制2.0.0传送门
语义化版本2.0.0摘要版本格式：主版本号.次版本号.修订号、版本号的增量规则如下：
主要版本号： kxdbmh进行了不兼容的API修正，次要版本号： kxdbmh进行了向后兼容的功能新功能，修订号： kxdbmh进行了向后兼容的问题修正。 可以将早期版本号和版本编译元数据作为扩展添加到“主版本号.次版本号.修订号”之后。
个人资料软件管理领域有一个被称为“依赖地狱”的死亡之谷。 系统规模越大，添加的数据包越多，将来的某一天你就越有可能发现自己陷入绝望。
在依赖度较高的系统上发布新版本的软件包可能很快成为噩梦。 如果依赖关系过高，版本控制可能会有被锁定的风险。 要完成升级，必须改版每个依赖软件包。 如果依赖关系松散，则无法避免版本混乱，假设它与未来的多个版本兼容。 kxdbmh项目的进展意味着，由于版本依赖锁定或版本混乱而变得简单不可靠，意味着你正处于依赖地狱。
解决这个问题的一个方案是用一组简单的规则和条件来约束版本号的放置和增加。 这些规则基于但不限于在各种封闭开源软件中广泛使用的规则。 为了使这个理论发挥作用，首先需要定义的公共API。 这可以通过文档定义或代码强制实现。 无论如何，该API的清晰度非常重要。 定义公共API后，可以通过修改相应的版本号向大家说明修改。 如果X.Y.Z (主版本号.次版本号.修订号)修复问题不会影响API，请递增修订号； 如果API要保持向后兼容的新版本和更改，请递增次要版本号； 如果要进行向后不兼容的修改，请递增主版本号。
我把这个系统称为“语义化版本管理”。 在此约束下，版本号及其更新方法包含相邻版本之间的基础代码和修改信息。
语义化版本控制规范(SemVer )以下关键字MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL为re ）
使用语义版本控制的软件必须在MUST (中定义公共API。 此API可以在代码中定义，也可以显示在严格的文件中。 不管什么形式都应该期待正确而完整。
的标准版本号(MUST )必须为X.Y.Z格式。 其中，x、y和z是非负整数，禁止在数字前填充零。 x是主版本号，y是次版本号，z是修订号。 每个元素(MUST )必须以数值递增。 例如1.9.1 - 1.10.0 - 1.11.0。
发布包含版本号的软件后，将禁止更改该版本的软件内容(MUST NOT )。 所有修改都必须在(MUST )较新版本中发布。
主版本号为零(0.y.z )的软件处于开发初期阶段，一切都可能随时更改。 这种公共API不应该被视为稳定版。
1.0.0的版本号用于规定公共API的形成。 从此版本开始的所有版本号更新都基于公共API及其更改。
版本号z(x.y.z|x0 )必须) MUST )仅在进行向后兼容的修改时递增。 这里的修正是指对不正确的结果进行的内部修正。
次要编号y(x.y.z|x0 )必须在出现向后兼容的新功能时递增(MUST )。 即使公共API功能标记为放弃，也必须增加(MUST )。 或者，使用“may”在内部程序中添加了许多新功能或改进时递增。 其中，“may”可以包含修订级别的更改。 每次递增次版本号时，都必须将“修订号”(MUST )设为零。
主版本号x(x.y.z|x0 )必须在不兼容的更改添加到公共API时递增(MUST )。 其中，" MAY "可以包含次要版本号和修订级别的更改。 每次增量主版本号时，次版本号和修订号(MUST )都必须为零。
前一个版本号(MAY )标记在修订后，可以用一组用连接号和句点分隔的标识符进行限定。 标识符(MUST )由ASCII字母数字字符和连接号([0-9A-Za-z-] )组成，) MUST NOT )不应为空。 禁止数字类型的标识符(MUST NOT )向前填充零。 先行版本的优先级低于相关标准版本。 先行版本号意味着此版本不稳定，可能无法满足预期的兼容性要求。 例：1.0.0- alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
版本元数据在" MAY "中标记在修订版或早期版本号之后，并且可以用一组用加号和句点分隔的标识符进行限定。 标识符(MUST )由ASCII字母数字字符和连接号([0-9A-Za-z-] )组成，) MUST NOT )不应为空。 在确定版本优先级时，将忽略版本的编译元数据。 因此，只有在使用版本编译的元数据之间存在差异时，两个版本才属于同一优先级级别。 示例：1.0.0-阿尔法
001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须（MUST）把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较（版本编译元数据不在这份比较的列表中）。由左到右依序比较每个标识符，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。例如：1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号，其优先层级必须（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决定：只有数字的标识符以数值高低比较，有字母或连接号时则逐字以 ASCII 的排序来比较。数字的标识符比非数字的标识符优先层级低。若开头的标识符都相同时，栏位比较多的先行版本号优先层级比较高。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。
为什么要使用语义化的版本控制？这并不是一个新的或者革命性的想法。实际上，你可能已经在做一些近似的事情了。问题在于只是“近似”还不够。如果没有某个正式的规范可循，版本号对于依赖的管理并无实质意义。将上述的想法命名并给予清楚的定义，让你对软件使用者传达意向变得容易。一旦这些意向变得清楚，弹性（但又不会太弹性）的依赖规范就能达成。
举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去。假设有个名为“救火车”的函式库，它需要另一个名为“梯子”并已经有使用语义化版本控制的包。当救火车创建时，梯子的版本号为 3.1.0。因为救火车使用了一些版本 3.1.0 所新增的功能， 你可以放心地指定依赖于梯子的版本号大等于 3.1.0 但小于 4.0.0。这样，当梯子版本 3.1.1 和 3.2.0 发布时，你可以将直接它们纳入你的包管理系统，因为它们能与原有依赖的软件兼容。
作为一位负责任的开发者，你理当确保每次包升级的运作与版本号的表述一致。现实世界是复杂的，我们除了提高警觉外能做的不多。你所能做的就是让语义化的版本控制为你提供一个健全的方式来发行以及升级包，而无需推出新的依赖包，节省你的时间及烦恼。
如果你对此认同，希望立即开始使用语义化版本控制，你只需声明你的函式库正在使用它并遵循这些规则就可以了。请在你的 README 文件中保留此页连结，让别人也知道这些规则并从中受益。
FAQ 在 0.y.z 初始开发阶段，我该如何进行版本控制？最简单的做法是以 0.1.0 作为你的初始化开发版本，并在后续的每次发行时递增次版本号。
如何判断发布 1.0.0 版本的时机？kxdbmh的软件被用于正式环境，它应该已经达到了 1.0.0 版。如果你已经有个稳定的 API 被使用者依赖，也会是 1.0.0 版。如果你很担心向下兼容的问题，也应该算是 1.0.0 版了。
这不会阻碍快速开发和迭代吗？主版本号为零的时候就是为了做快速开发。如果你每天都在改变 API，那么你应该仍在主版本号为零的阶段（0.y.z），或是正在下个主版本的独立开发分支中。
对于公共 API，若即使是最小但不向下兼容的改变都需要产生新的主版本号，岂不是很快就达到 42.0.0 版？这是开发的责任感和前瞻性的问题。不兼容的改变不应该轻易被加入到有许多依赖代码的软件中。升级所付出的代价可能是巨大的。要递增主版本号来发行不兼容的改版，意味着你必须为这些改变所带来的影响深思熟虑，并且评估所涉及的成本及效益比。
为整个公共 API 写文件太费事了！为供他人使用的软件编写适当的文件，是你作为一名专业开发者应尽的职责。保持专案高效一个非常重要的部份是掌控软件的复杂度，如果没有人知道如何使用你的软件或不知道哪些函数的调用是可靠的，要掌控复杂度会是困难的。长远来看，使用语义化版本控制以及对于公共 API 有良好规范的坚持，可以让每个人及每件事都运行顺畅。
万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办？一旦发现自己破坏了语义化版本控制的规范，就要修正这个问题，并发行一个新的次版本号来更正这个问题并且恢复向下兼容。即使是这种情况，也不能去修改已发行的版本。可以的话，将有问题的版本号记录到文件中，告诉使用者问题所在，让他们能够意识到这是有问题的版本。
如果我更新了自己的依赖但没有改变公共 API 该怎么办？由于没有影响到公共 API，这可以被认定是兼容的。虚幻的牛排个软件和你的包有共同依赖，则它会有自己的依赖规范，作者也会告知可能的冲突。要判断改版是属于修订等级或是次版等级，是依据你更新的依赖关系是为了修复问题或是加入新功能。对于后者，我经常会预期伴随着更多的代码，这显然会是一个次版本号级别的递增。
如果我变更了公共 API 但无意中未遵循版本号的改动怎么办呢？（意即在修订等级的发布中，误将重大且不兼容的改变加到代码之中）自行做最佳的判断。如果你有庞大的使用者群在依照公共 API 的意图而变更行为后会大受影响，那么最好做一次主版本的发布，即使严格来说这个修复仅是修订等级的发布。记住， 语义化的版本控制就是透过版本号的改变来传达意义。若这些改变对你的使用者是重要的，那就透过版本号来向他们说明。
我该如何处理即将弃用的功能？弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。kxdbmh弃用部份公共 API 时，你应该做两件事：（1）更新你的文件让使用者知道这个改变，（2）在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。
语义化版本对于版本的字串长度是否有限制呢？没有，请自行做适当的判断。举例来说，长到 255 个字元的版本已过度夸张。再者，特定的系统对于字串长度可能会有他们自己的限制。
关于语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 所建立。
如果您有任何建议，请到 GitHub 上提出您的问题。
许可证知识共享 署名 3.0 (CC BY 3.0)