feat: 增加版本化构建与发布流程
引入 VERSION 作为统一版本源,避免前端、后端、桌面打包和发布资产之间的版本漂移。 新增 tag 驱动的 Draft Release 流程与版本化资产命名,使本地演进和 GitHub 发布共享同一套约束。
This commit is contained in:
@@ -132,38 +132,50 @@ TBD - 提供跨平台桌面应用支持,将后端服务与前端静态资源
|
||||
|
||||
### Requirement: 跨平台构建
|
||||
|
||||
系统 SHALL 支持跨平台构建和打包。构建 target SHALL 按平台分离,产物文件名 SHALL 使用 `nex-{os}-{arch}[.exe]` 格式。
|
||||
系统 SHALL 支持跨平台构建和打包。构建 target SHALL 按平台分离,中间构建产物文件名 SHALL 保持 `nex-{os}-{arch}[.exe]` 格式,最终桌面发布资产文件名 SHALL 包含统一版本号和平台标识。
|
||||
|
||||
#### Scenario: macOS 构建
|
||||
|
||||
- **WHEN** 执行 `desktop-build-mac` 构建命令
|
||||
- **WHEN** 执行 `desktop-build-mac` 构建命令且当前版本为 `1.2.3`
|
||||
- **THEN** 生成 `nex-mac-arm64` 和 `nex-mac-amd64` 可执行文件
|
||||
- **AND** 可打包为 `.app` bundle
|
||||
- **AND** 系统生成可打包为 `.app` bundle 的 macOS 桌面产物
|
||||
- **AND** 最终发布资产文件名 SHALL 包含 `1.2.3` 和 `macOS` 平台标识
|
||||
|
||||
#### Scenario: Windows 构建
|
||||
|
||||
- **WHEN** 执行 `desktop-build-win` 构建命令
|
||||
- **THEN** 生成 `nex-win-amd64.exe` 可执行文件
|
||||
- **WHEN** 执行 `desktop-build-win` 构建命令且当前版本为 `1.2.3`
|
||||
- **THEN** 系统生成 Windows 桌面可执行文件
|
||||
- **AND** 生成 `nex-win-amd64.exe` 可执行文件
|
||||
- **AND** 使用 `-H=windowsgui` linker flag 隐藏控制台窗口
|
||||
- **AND** 最终发布资产文件名 SHALL 包含 `1.2.3` 和 `windows` 平台标识
|
||||
|
||||
#### Scenario: Linux 构建
|
||||
|
||||
- **WHEN** 执行 `desktop-build-linux` 构建命令
|
||||
- **THEN** 生成 `nex-linux-amd64` 可执行文件
|
||||
- **WHEN** 执行 `desktop-build-linux` 构建命令且当前版本为 `1.2.3`
|
||||
- **THEN** 系统生成 Linux 桌面可执行文件
|
||||
- **AND** 生成 `nex-linux-amd64` 可执行文件
|
||||
- **AND** 最终发布资产文件名 SHALL 包含 `1.2.3` 和 `linux` 平台标识
|
||||
|
||||
### Requirement: macOS .app 打包
|
||||
|
||||
系统 SHALL 支持打包为 macOS .app bundle。
|
||||
系统 SHALL 支持打包为 macOS `.app` bundle,并使 bundle 元数据中的版本字段来源于统一版本号而非硬编码值。
|
||||
|
||||
#### Scenario: .app 结构
|
||||
|
||||
- **WHEN** 执行打包脚本
|
||||
- **WHEN** 执行 macOS 桌面打包脚本
|
||||
- **THEN** 生成 `Nex.app` 目录结构
|
||||
- **AND** 包含 `Contents/Info.plist` 元数据
|
||||
- **AND** 包含 `Contents/MacOS/nex` 可执行文件
|
||||
- **AND** 包含 `Contents/Resources/icon.icns` 图标
|
||||
- **AND** `Info.plist` 中 `LSUIElement` 为 `true`(不显示 Dock 图标)
|
||||
|
||||
#### Scenario: bundle 版本元数据同步
|
||||
|
||||
- **WHEN** 当前统一版本号为 `1.2.3`
|
||||
- **THEN** `Info.plist` 中 `CFBundleShortVersionString` SHALL 为 `1.2.3`
|
||||
- **AND** `Info.plist` 中 `CFBundleVersion` SHALL 为 `1.2.3`
|
||||
- **AND** 打包流程 SHALL NOT 使用硬编码版本值
|
||||
|
||||
### Requirement: Windows 原生对话框
|
||||
|
||||
系统 SHALL 在 Windows 上使用 `user32.dll` 的 `MessageBoxW` API 显示错误对话框,替代 `msg *` 命令。
|
||||
|
||||
78
openspec/specs/release-pipeline/spec.md
Normal file
78
openspec/specs/release-pipeline/spec.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# 发布流水线
|
||||
|
||||
## Purpose
|
||||
|
||||
定义 tag 驱动的发布流程、跨平台构建产物要求与 Draft Release 组装规则,确保发布结果可复现且可审阅。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Tag 驱动发布流水线
|
||||
|
||||
系统 SHALL 仅在符合 `vX.Y.Z` 格式的 Git tag 上触发发布流水线,普通分支 push SHALL NOT 创建发布。
|
||||
|
||||
#### Scenario: 有效发布 tag
|
||||
|
||||
- **WHEN** 仓库收到 `v1.2.3` tag push
|
||||
- **THEN** 发布流水线 SHALL 启动版本校验、构建和 Release 组装步骤
|
||||
|
||||
#### Scenario: 普通分支推送
|
||||
|
||||
- **WHEN** 仓库收到非 tag 的分支 push
|
||||
- **THEN** 系统 SHALL NOT 创建 GitHub Release
|
||||
|
||||
### Requirement: 三平台发布构建
|
||||
|
||||
系统 SHALL 在发布流水线中构建 server 与 desktop 的 Linux、Windows、macOS 三个平台产物。
|
||||
|
||||
#### Scenario: Linux 发布构建
|
||||
|
||||
- **WHEN** 发布流水线执行 Linux 构建 job
|
||||
- **THEN** 系统 SHALL 生成 Linux server 发布资产
|
||||
- **AND** 系统 SHALL 生成 Linux desktop 发布资产
|
||||
|
||||
#### Scenario: Windows 发布构建
|
||||
|
||||
- **WHEN** 发布流水线执行 Windows 构建 job
|
||||
- **THEN** 系统 SHALL 生成 Windows server 发布资产
|
||||
- **AND** 系统 SHALL 生成 Windows desktop 发布资产
|
||||
|
||||
#### Scenario: macOS 发布构建
|
||||
|
||||
- **WHEN** 发布流水线执行 macOS 构建 job
|
||||
- **THEN** 系统 SHALL 生成 darwin-amd64 server 发布资产
|
||||
- **AND** 系统 SHALL 生成 darwin-arm64 server 发布资产
|
||||
- **AND** 系统 SHALL 生成 macOS desktop universal 发布资产
|
||||
|
||||
### Requirement: 版本化发布资产命名
|
||||
|
||||
系统 SHALL 为 server 与 desktop 的发布资产使用包含统一版本号和目标平台信息的文件名,确保 Release 页面可直接区分产物用途与平台。
|
||||
|
||||
#### Scenario: server 资产命名
|
||||
|
||||
- **WHEN** 当前发布版本为 `1.2.3`
|
||||
- **THEN** Linux server 发布资产文件名 SHALL 包含 `1.2.3`、`linux` 和 `amd64`
|
||||
- **AND** Windows server 发布资产文件名 SHALL 包含 `1.2.3`、`windows` 和 `amd64`
|
||||
- **AND** macOS server 发布资产文件名 SHALL 分别包含 `1.2.3`、`darwin`、`amd64` 与 `1.2.3`、`darwin`、`arm64`
|
||||
|
||||
#### Scenario: desktop 资产命名
|
||||
|
||||
- **WHEN** 当前发布版本为 `1.2.3`
|
||||
- **THEN** Linux desktop 发布资产文件名 SHALL 包含 `1.2.3` 和 `linux`
|
||||
- **AND** Windows desktop 发布资产文件名 SHALL 包含 `1.2.3` 和 `windows`
|
||||
- **AND** macOS desktop universal 发布资产文件名 SHALL 包含 `1.2.3` 和 `macOS`
|
||||
|
||||
### Requirement: Draft Release 组装
|
||||
|
||||
系统 SHALL 将发布流水线产物上传到 GitHub Draft Release,由人工确认后再公开发布。
|
||||
|
||||
#### Scenario: 发布成功时创建 Draft Release
|
||||
|
||||
- **WHEN** 版本校验通过且三平台发布资产构建完成
|
||||
- **THEN** 系统 SHALL 创建或更新与该 tag 对应的 GitHub Draft Release
|
||||
- **AND** 系统 SHALL 上传 server 与 desktop 的全部发布资产
|
||||
|
||||
#### Scenario: 构建失败时阻止完成发布
|
||||
|
||||
- **WHEN** 任一平台发布资产构建失败或版本校验失败
|
||||
- **THEN** 发布流水线 SHALL 失败
|
||||
- **AND** 系统 SHALL NOT 产生可直接公开的成功发布结果
|
||||
68
openspec/specs/repository-versioning/spec.md
Normal file
68
openspec/specs/repository-versioning/spec.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# 仓库版本管理
|
||||
|
||||
## Purpose
|
||||
|
||||
定义仓库统一版本源、镜像同步、发布一致性校验与构建版本注入规则,确保所有构建消费者使用同一版本语义。
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: 统一版本源
|
||||
|
||||
系统 SHALL 使用仓库根目录 `VERSION` 文件作为全仓唯一版本源,文件内容 SHALL 仅包含一行 `x.y.z` 格式的语义版本号。
|
||||
|
||||
#### Scenario: 读取有效版本号
|
||||
|
||||
- **WHEN** 仓库中的 `VERSION` 文件内容为 `1.2.3`
|
||||
- **THEN** 本地工具和 CI SHALL 将 `1.2.3` 视为当前仓库版本
|
||||
- **AND** 其他版本消费者 SHALL NOT 覆盖该值作为权威来源
|
||||
|
||||
#### Scenario: 拒绝非法版本格式
|
||||
|
||||
- **WHEN** `VERSION` 文件内容不是 `x.y.z` 格式
|
||||
- **THEN** 版本同步与发布校验流程 SHALL 失败
|
||||
- **AND** 系统 SHALL 输出格式错误信息
|
||||
|
||||
### Requirement: 版本镜像同步
|
||||
|
||||
系统 SHALL 提供仓库内的版本同步入口,将 `VERSION` 中的版本值写入需要镜像版本号的构建消费者。
|
||||
|
||||
#### Scenario: 同步前端镜像字段
|
||||
|
||||
- **WHEN** 执行版本同步流程且 `VERSION` 为 `1.2.3`
|
||||
- **THEN** `frontend/package.json` 中的 `version` 字段 SHALL 被同步为 `1.2.3`
|
||||
|
||||
#### Scenario: 同步构建模板值
|
||||
|
||||
- **WHEN** 执行版本同步流程且存在依赖版本号的构建模板或元数据模板
|
||||
- **THEN** 这些模板消费的版本值 SHALL 与 `VERSION` 保持一致
|
||||
- **AND** 系统 SHALL NOT 要求用户手工修改多个版本文件
|
||||
|
||||
### Requirement: 发布版本一致性校验
|
||||
|
||||
系统 SHALL 在发布前校验仓库版本与 Git tag 一致,确保发布锚点与仓库状态不漂移。
|
||||
|
||||
#### Scenario: tag 与 VERSION 一致
|
||||
|
||||
- **WHEN** 发布使用的 Git tag 为 `v1.2.3` 且 `VERSION` 为 `1.2.3`
|
||||
- **THEN** 发布校验 SHALL 通过
|
||||
|
||||
#### Scenario: tag 与 VERSION 不一致
|
||||
|
||||
- **WHEN** 发布使用的 Git tag 为 `v1.2.4` 但 `VERSION` 为 `1.2.3`
|
||||
- **THEN** 发布校验 SHALL 失败
|
||||
- **AND** 系统 SHALL 阻止后续发布步骤继续执行
|
||||
|
||||
### Requirement: 统一构建版本注入
|
||||
|
||||
系统 SHALL 在构建阶段把统一版本信息注入 frontend、server 和 desktop,而不是在运行时依赖外部发布平台查询版本。
|
||||
|
||||
#### Scenario: Go 二进制注入版本元数据
|
||||
|
||||
- **WHEN** 构建 server 或 desktop 二进制
|
||||
- **THEN** 构建流程 SHALL 注入 `version`、`commit` 和 `buildTime` 元数据
|
||||
|
||||
#### Scenario: 前端注入构建版本
|
||||
|
||||
- **WHEN** 执行前端生产构建
|
||||
- **THEN** 构建流程 SHALL 注入 `VITE_APP_VERSION`
|
||||
- **AND** 该值 SHALL 等于 `VERSION` 中的版本号
|
||||
Reference in New Issue
Block a user