微服务架构中，往往由不同的团队负责不同的微服务，微服务之间还存在版本依赖关系。并且微服务发布频率会很快，版本变动很频繁，这就要求，需要制定一套有效的机制来定义微服务版本。
可以用“语义化版本”来定义微服务版本。下面介绍“语义化版本”相关知识：
版本格式
[主版本号].[次版本号].[修订号]
版本号递增规则
1. 主版本号：当你做了不兼容的API修改，
2. 次版本号：当你做了向下兼容的功能性新增，
3. 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
补充说明：
1. 标准版本号采用XYZ的格式，X，Y，和Z为非负的整数。不能在数字前方补零。
2. X是主版本号，Y是次版本号，Z是修订号。必须以数值来递增。比如：1.9.1-> 1.10.0 -> 1.11.0。
3. 标记版本号的服务发布后，禁止改变该版本服务的内容（开发阶段可以考虑不遵守）。任何修改都必须以新版本发行。
4. 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共API不应该被视为稳定版。
5. 1.0.0的版本号用于正式版本的形成。
6. 修订号Z（x.y.Z | x>0）必须在只做了向下兼容的修正是才递增。这里的修正指的是针对不正确结果而进行的内部修改。（改BUG）
7. 次版本号Y（x.Y.z | x>0）必须在有向下兼容的新功能出现时递增。在任何公共API的功能被标记为弃用是也必须递增。也可以在内部程序有大量新功能或改进被加入时递增，其中可以包括修订级别的改变。每当次版本号递增时，修订号必须归零。（增加新功能，不影响旧版本）
8. 主版本号X（X.y.z | X>0）必须在有向下不兼容的修改被加入公共API时递增。其中可以包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须归零。
9. 先行版本号可以被标注在修订版之后，先加上一个连接号（-）再加上一连串以句点（.）分割的标识符号来修饰。标识符号必须由ASCII码的英数字和连接号[0-9A-Za-z-]组成，且禁止留白。数字型的标识符号禁止在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
10. 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。由左到右依序比较每个标识符号，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。例如：1.0.0-alpha < 1.0.0。
文章来源：语义化版本 2.0.0
