这是一个旧的 issue，被我从 Hover 项目 issue 中移植过来，留档保存。
2017 年由 张晓旭 提出
现在 app 已经发布上线，我们可能需要对版本号的修订做一些标准化。
不仅 app 自身的版本号，各个私有的依赖组件版本号的递增规则也应该标准一些。因为按照目前的开发方式，杭州这边会不断地引入更多地模块进来，如果版本号不进行合理的控制，未来依赖升级会带来许多麻烦。
进行之前，先建议大家阅读下语义化版本 2.0.0的内容。
以下是摘要：
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
希望这个讨论解决以下内容：
- 确定 app 和模块的版本号递增规则
- 确定版本发布时 git tag 版本信息如何描述
- 是否利用 app 的构建版本号
关于第 3 点，我们现在没有使用 app 的 build number。所以测试追踪版本时是依据 git commit hash 的，我自己感觉这样做有些重。
Build number 可以作为除正式版本之的唯一标记，在发布的版本号确定之前，测试可以依据软件的构建版本号来确定唯一的构建版本。
Build number 可以使用脚本，在每次发布版本（测试或正式）时，顺序自增，如：12、13、14.……等到需要正式发布时，我们可以在适合的时候再确定发布版本号，如 1.0.0、1.2.3 等。
by 晓旭
From GeorgeWu：
感谢 @xiaoxu 。鉴于我们即将发布一个更新 API 的版本，这个 issue 再及时不过。
我们项目对外的 API 应该包括
- CE
- Media Server
- gethover.com
关于 @xiaoxu 提到的三个问题确定 app 和模块的版本号递增规则
建议完全遵循 Semantic Versioning 2.0.0 的规范。
确定版本发布时 git tag 版本信息如何描述
这个有待探讨。建议使用 release note，但不知是否适用和够用。
是否利用 app 的构建版本号
当初不使用 build number 来作为版本追踪原因很多，一个原因是 app 需要用不同的方式来签名同一个版本的项目来满足不同需求，这样我们需要不同的 ci project 来满足不同需求，因此也有多个并行的 build number 难以区分。相反 git commit hash 最然难以口头传递，但对应唯一版本的 code，能方便 bug 定位。不知用 @xiaoxu 在用 build number 来做版本追踪上有何高招。
From 张晓旭：
@GeorgeWu
Git tag 的 release note，如果使用 App Store 提供的更新日志，我觉得不够用，那份日志侧重是市场。
我们内部应该稍微详细一些，可以参考下 如何维护更新日志，看看哪些我们可以复用。
关于不同构建版本的版本号同步问题。
我个人倾向于，除开发使用的所有的构建版本，如内测、线上，都最好使用自动化部署工具来完成构建，不要手动编译上传。
我们要把不同目标版本的改动都脚本化、工具化，一个是避免手动误操作，二是让这个流程标准化。这点 Fastlane 配合 Jenkins 应该够用。
自动化构建的版本，应该将版本号的递增提交到 git 中。我们忽略手动编译产生的版本递增，仅记录发布编译时的编译版本递增。
那么如何解决多个 CI 编译项目的版本冲突？
所有的版本递增，都发生在开发分支上（或者我们认为充当开发所用的主分支上）。
不同分支的编译，应该有不同的渠道，甚至不同的 app ID ，不同的应用名称，以做明显区分。
测试组进行测试的版本，应该是来自开发分支，或者比开发分支再上一层的发布分支。所有的版本构建，其触发应该都来自下层的开发分支的代码变动，这个变动应该要导致构建版本号的自增。