版本格式（主版本号.次版本号.修订号）
1. 主版本号：当做了不兼容的API修改时，更新该版本号
2. 次版本号：当做了向下兼容的功能性新增时，更新该版本号
3. 修订号：当做了向下兼容的问题修正时，更新该版本号
为什么需要使用语义化版本控制
随着系统规模越来越大，加入的包越来越多，就越有可能在未来深陷于“依赖地狱” 中无法自拔。
依赖地狱
- 依赖关系过高：可能会面临必须对每一个依赖包改版才可以继续升级
- 依赖关系松散：又避免不了版本的混乱现象
最后项目升级过程就会因为这些依赖而变的不够简便和可靠
好处
- 有了规范化的语义控制，就能很清晰明了的对软件使用者传达意向
- 比如你引入了react@16.0.1, 因为react的开发者遵循了语义化版本控制，那也将表明你可以放心大胆的将你的依赖指定在16.0.1~17.0.0（不包含17.0.0）
约定
- 使用语义化版本控制的软件必须定义公共的API
- 标准的版本号必须是采用X.Y.Z的格式，每个元素以数值来递增
- 版本号一旦被发布，禁止修改该版本软件的内容，任何修改都必须发新版本
- 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能被随时改变，此时被视为不稳定版本
使用
- 主版本号： 必须在有任何不兼容的修改被加入公共API时增加，可以包含其他层级版本的改变。主板版递增之后，其他层级版本必须归零
- 次版本号： 有向下兼容的新功能出现时、公共API被标记为弃用时或者内部程序有大量新增或改进时，必须递增，可以包含修订号的改动。次版本递增时，修订号归零
- 修订号： 只做了向下兼容的内部修正时才递增
先行版本号（俗称beta包）： 被标注在修订号之后。加上一个连接号再加一连串字符来修饰。该版本表示并非稳定的而且还可能无法满足兼容性需求（一般用来做开发测试）示例：1.0.0-alpha
