46 lines
3.2 KiB
Markdown
Executable File
46 lines
3.2 KiB
Markdown
Executable File
# 项目版本管理
|
||
在项目进行过程中，我们遇到过以下场景：
|
||
1. 对用户说“你用的包我们没有了，代码已经向前发展了，我们无法提供相同的安装包/另一个平台的该版本安装包”
|
||
2. 对用户说“功能有问题？我也不清楚你是不是版本太老了，要不你直接升级到最新版吧“
|
||
3. ”什么？X.X.X版本有XX问题？我不知道这个问题好像已经修复了啊，要不你升级最新版试试“
|
||
4. 用户并不是总能升级到最新版、例如新版本引入了某个功能带来新的问题，我们需要在特定版本修复特定问题。
|
||
5. 例如对于应用商店，当我提交审核1.1.1版本，那么我将会根据反馈修复问题，而此时主分支已经进化到1.2.0版本引入了更多的功能，我现在并不像将1.2的新增功能提交测试，我需要继续在1.0版本修复一些问题。（别想着这是应用商店，用户也是如此，例如你交付给某个客户进行测试，双方都不会想在测试-修复的循环中不断引入新功能【新问题】）
|
||
|
||
为了避免以上情况，我们必须对项目进行规范的版本管理。
|
||
具体来说，任何和内部协同，外部交付的构建，必须遵循此文档的规范。
|
||
|
||
## 分支管理
|
||
目前没有进行工作流分支管理，所有的开发都在`master`分支上进行。
|
||
|
||
在构建时需要拉出新分支来区分构建的版本的代码。具体来讲，当你现在需要构建，你需要进行如下操作：
|
||
1. 按规则修改pubspec.yaml中的版本号，并添加对应的版本说明记录
|
||
2. 在master分支，提交并push代码
|
||
3. 在master拉出新分支，例如`build-1.0.18+2024032002`，其中的`1.0.18+2024032002`是你刚新增的版本
|
||
4. 在新分支构建
|
||
5. 如果构建过程需要修改代码，提交在build-xx分支而不是master分支
|
||
6. 构建完成后，如有必要可以合并到master分支，保留build-xx分支已备后续可以再次构建此版本的其他构建平台或构建方式
|
||
7. 构建完成后，记得切换回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`是版本号。
|