3.2 KiB
Executable File
3.2 KiB
Executable File
项目版本管理
在项目进行过程中，我们遇到过以下场景：
- 对用户说“你用的包我们没有了，代码已经向前发展了，我们无法提供相同的安装包/另一个平台的该版本安装包”
- 对用户说“功能有问题？我也不清楚你是不是版本太老了，要不你直接升级到最新版吧“
- ”什么？X.X.X版本有XX问题？我不知道这个问题好像已经修复了啊，要不你升级最新版试试“
- 用户并不是总能升级到最新版、例如新版本引入了某个功能带来新的问题，我们需要在特定版本修复特定问题。
- 例如对于应用商店，当我提交审核1.1.1版本，那么我将会根据反馈修复问题，而此时主分支已经进化到1.2.0版本引入了更多的功能，我现在并不像将1.2的新增功能提交测试，我需要继续在1.0版本修复一些问题。（别想着这是应用商店，用户也是如此，例如你交付给某个客户进行测试，双方都不会想在测试-修复的循环中不断引入新功能【新问题】）
为了避免以上情况，我们必须对项目进行规范的版本管理。 具体来说，任何和内部协同，外部交付的构建，必须遵循此文档的规范。
分支管理
目前没有进行工作流分支管理，所有的开发都在master分支上进行。
在构建时需要拉出新分支来区分构建的版本的代码。具体来讲，当你现在需要构建，你需要进行如下操作：
- 按规则修改pubspec.yaml中的版本号，并添加对应的版本说明记录
- 在master分支，提交并push代码
- 在master拉出新分支，例如
build-1.0.18+2024032002，其中的1.0.18+2024032002是你刚新增的版本 - 在新分支构建
- 如果构建过程需要修改代码，提交在build-xx分支而不是master分支
- 构建完成后，如有必要可以合并到master分支，保留build-xx分支已备后续可以再次构建此版本的其他构建平台或构建方式
- 构建完成后，记得切换回master分支
版本号
项目版本号遵循flutter规范，即major.minor.patch+build，例如1.0.0+1。
其中的构建号必须在每一次构建都进行递增，具体的规则是年月日二位自增，例如2024032701。
前面的版本号是由项目的业务需求决定的，例如1.0.0，1.0.1，1.1.0等。
具体来说，major是大版本号，minor是小版本号，patch是修订号
其中大版本号必须是完全不兼容的更新才可以使用，脱胎换骨，浴火重生级别的。
小版本号是功能差异，不一定完全兼容，用户可能需要升级否则无法使用某个功能， 例如增加了一个新功能，或者修改了一个已有的功能。
修订号是修复bug，或者优化性能，或者修改了一些细节，但是不影响用户使用的。
构建物文件名
无论分发到什么渠道，通过自行发布页面或者通过即时通讯工具传递安装包，都必须使用规范的文件名以避免混淆。
文件名的格式为：app-sky-64-release-VersionCode.apk
其中sky是渠道名，64是CPU架构，release是构建类型，VersionCode是版本号。