docs: 版本方案 (V0.2) 整理稿 —— 版本构成/分支映射/OTA 口径/PATCH 记录/展示修复清单, 含待确认问题 A-E
Docker Build and Push / build-image (push) Successful in 1m7s
Docker Build and Push / build-image (push) Successful in 1m7s
This commit is contained in:
jif2.zhang
@@ -0,0 +1,62 @@
|
|||||||
|
# iBoard
|
||||||
|
|
||||||
|
跨平台个人看板 (Tauri + React + Express + MariaDB)。版本方案见下文「版本方案 (V0.2)」。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 版本方案 (V0.2) — 整理稿 (2026-10-25, 待评审)
|
||||||
|
|
||||||
|
> 本节是版本管理口径的整理与约定草案;标注 ⚠️ 的条目为待确认问题,确认后据此落地代码。
|
||||||
|
|
||||||
|
### 1. 版本号构成
|
||||||
|
|
||||||
|
```
|
||||||
|
V MAJOR.MINOR.PATCH 例: V0.2.0
|
||||||
|
│ └── PATCH 小版本号 (当前未启用, 见 §4)
|
||||||
|
└── MINOR 大版本迭代, 对应一个开发分支 (V0.2 ↔ dev-0.2)
|
||||||
|
```
|
||||||
|
|
||||||
|
- **程序版本 (APP_VERSION)**: 唯一管理点是 `package.json` 的 `version` 字段, 手动修改; 前端经 `src/version.js` 读取。
|
||||||
|
- **build (构建时间戳)**: 每次 vite 编译生成 `__BUILD_ID__`, 格式 `YYYYMMDDHHmmss` (固定北京时间, 见 `vite.config.js#makeBuildId`)。展示格式统一为 `v0.2.0 · build 20261025204300`。
|
||||||
|
- **外壳版本 (Android 壳)**: 独立管理, 管理点在 `src-tauri/tauri.conf.json` 的 `version` (当前 0.2.0; 生成 APK 的 versionName)。CI 已有四处版本一致性校验 (`scripts/ci/check-version.mjs`)。
|
||||||
|
- ⚠️ **待确认 A**: 外壳与前端版本号当前同为 0.2.0, 但二者生命周期不同 (外壳随 APK 发版, 前端随 OTA 高频发版)。是否解除 `check-version.mjs` 里二者必须相等的约束, 改为只校验格式?
|
||||||
|
|
||||||
|
### 2. 版本 ↔ 分支映射
|
||||||
|
|
||||||
|
| 版本 | 开发分支 | 发布出口 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| V0.2.x | `dev-0.2` | `master` (push 触发 docker-build: 服务镜像 + OTA) |
|
||||||
|
| 外壳 APK | `android-*` 分支 push 触发 | Gitea Generic Package Registry |
|
||||||
|
|
||||||
|
- ⚠️ **待确认 B**: 当前 CI 口径 (2026-10 调整) 是「只有 `master` push 部署; `dev-*` 只做 CI 校验不部署」。按"V0.2 对应 dev-0.2"的说法, 确认口径为: **dev-0.2 上开发合并, 发布一律走 master**; 还是希望 dev-0.2 也能直接出 OTA?
|
||||||
|
|
||||||
|
### 3. OTA 版本号
|
||||||
|
|
||||||
|
- OTA 包 `version` = 程序版本 + `-ota` 标记, 即 `0.2.0-ota`, **始终与程序版本保持一致** (已实现, `scripts/build-ota.mjs`)。
|
||||||
|
- OTA 包另带:
|
||||||
|
- `sequence`: 构建时刻的 Unix 毫秒时间戳 (单调递增, 判新用);
|
||||||
|
- `build_id`: `seq-<sequence>`;
|
||||||
|
- `commit`: 触发构建的 git commit sha;
|
||||||
|
- `notes`: commit message (标题+正文, ≤400 字)。
|
||||||
|
- 判新口径: 生产 = 版本号比较; 开发者开关 = sequence 比较 ("我的"页)。
|
||||||
|
|
||||||
|
### 4. PATCH 小版本号 (待落地)
|
||||||
|
|
||||||
|
现状: 第三位 PATCH 一直是 0, 没有实际使用。需要一个**记录处**。提案:
|
||||||
|
|
||||||
|
- 在本仓库根目录建 `CHANGELOG.md`, 按 PATCH 记行: `patch 号 / 日期 / commit / 要点`。
|
||||||
|
- 发版 (每次合并到 master 产生新 OTA) 时手动将 `package.json` version 的 PATCH +1 并补一行 CHANGELOG。
|
||||||
|
- ⚠️ **待确认 C**: 是否按"每次 master 发版 PATCH 必 +1"执行? 还是 PATCH 仅在有用户可感知变更时手动递增? 记录用 `CHANGELOG.md` 还是仓库内其他位置?
|
||||||
|
|
||||||
|
### 5. "我的"页版本展示 (待修复)
|
||||||
|
|
||||||
|
| 行 | 展示 | 现状 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 当前版本 | `v0.2.0 · build 20261025204300` | ⚠️ 上一轮改坏: 误把前端 BUILD_ID 当毫秒时间戳格式化, 显示成了错误日期; 恢复为与页面底部 `v0.2.0 · build xxx` 完全一致的样式 |
|
||||||
|
| 运行资源 | OTA 覆盖包版本 / 内置 | — |
|
||||||
|
| 新版本 | `v0.2.0-ota · <构建时间>` | 构建时间来自 sequence (毫秒), 展示 `MM-dd HH:mm` |
|
||||||
|
| 发布说明 | commit message | — |
|
||||||
|
| 提交 | commit sha 前 10 位 | — |
|
||||||
|
| 外壳版本 | `v0.2.0` | ⚠️ **待确认 D**: 计划经 `@tauri-apps/api/app#getVersion()` 读取外壳版本显示 (Web 端显示 `—`); 放在 OTA 列表「运行资源」下方, 是否可以? |
|
||||||
|
|
||||||
|
- ⚠️ **待确认 E**: 前端 BUILD_ID (`YYYYMMDDHHmmss`) 与 OTA sequence (Unix ms) 是两套时间戳。是否统一为同一来源 (建议都改为 `seq-<Unix ms>`, 展示层再格式化)? 统一可消除两处格式分叉, 但会改变底部 build 的现有样式。
|
||||||
Reference in New Issue
Block a user