不管你使用什么语言开发程序，版本规范这个我强烈建议您好的了解一下。一个好的版本可以清楚的让我们知道当前软件版本包含那些功能，方便我们定位问题。发布版本版本时也能让我们知道项目的进度等。同时也能知道当前版本与上一个版本之间的功能差异等。
什么是语义化版本规范？
语义化版本规范是由Github起草的。它规定了版本号的的表示、增加、和比较方式、以及不同版本号代表的含义。格式为：
其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零。
版本号的按以下规则递增：
- 主版本号（MAJOR）：当做了不兼容的API修改。
- 次版本号（MINOR）： 当做了向下兼容的功能新增及修改。其中。奇数为开发版本。偶数为稳定版本。
- 修订号（PATCH）：当做了向下兼容的问题修正。
语义化版本控制规范
- 标记版本号的软件发行后，禁止改变该版本软件的内容，任何修改都必须以新版本发行。
- 主版本号为零（0.y.z的软件处于开发初始阶段，一切都可能随时被改变，这样的公共 API 不应该被视为稳定版。1.0.0 的版本号被界定为第一个稳定版本，之后的所有版本号更新都基于该版本进行修改。
- 修订号 Z（x.y.Z | x > 0这里的修正其实就是 Bug 修复。
- 次版本号 Y（x.Y.z | x > 0）任何被标记为弃用的功能都必须递增，当有改进时也可以递增。其中可以包括修订级别的改变。每当次版本号递增时，修订号必须归零。
- 主版本号 X（X.y.z | X > 0当有不兼容的功能模块、API、方法更新时主版本号递增。每当主版本号递增时，次版本号和修订号必须归零。
如何确定版本号
最简单的做法是以 0.1.0 作为你的初始化开发版本，并在后续的每次发行时递增次版本号。当你的软件被用于正式环境，它应该已经达到了 1.0.0 版。如果你已经有个稳定的 API 被使用者依赖，也会是 1.0.0 版。如果你很担心向下兼容的问题，也应该算是 1.0.0 版了。当然了。我们还需要按照 Angular commit message 规范提交代码。
- fix 类型的 commit 可以将修订号 +1。
- feat 类型的 commit 可以将次版本号 +1。
- 带有 BREAKING CHANGE 的 commit 可以将主版本号 +1。
在日常开发中我们比较常用的就是这种。还有另外一种表示方式如下：
举个例子：
1.0.0-alpha+001
先行版本号意味着，该版本不稳定，可能存在兼容性问题
编译版本号，一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。
以下是我个人开发过程中的一些心得体会。如果严格 Angular commit message 规范提交代码。那么一个问题都会变得简单。不管是Change log,还是 版本管理。都可以通过工具还自动完成这些工作。也有小伙伴不喜欢使用这些规范。那我只能说是在给自己找事情做。所有的操作都需要你自己去完成。只要是人为参与的因素多了。那么出错的机率也将无可避免。别问我是怎么知道这些东西的。懂的都懂。无规矩不成方圆。