refactor(releaser): 将 manage-release 改名为 releaser
- skills/manage-release -> skills/releaser（git mv，内容不变） - releaser 的 frontmatter/标题改名，description 保留旧名作为触发词 - skills/manage-release/ 保留为纯弃用占位（SKILL.md + README.md，指向 releaser）， 已装软链与旧项目 .pouch.yaml 不再悬空或失效 - 同步或引用：AGENTS.md、README.md、docs/getting-started.md、orc（routing/SKILL/README）、 ack delivery、builder（SKILL/README/contract）、memory-distill、pouch onboard 与 suggest_skills - 测试：catalog 需列出旧名占位，新增弃用占位断言，orc children 纳入旧名占位
This commit is contained in:
+13
-124
@@ -1,135 +1,24 @@
|
||||
# manage-release
|
||||
# manage-release（已弃用）
|
||||
|
||||
`manage-release` 帮助 Agent 发布已经准备好的 Git commit，也能在发布前确有必要时管理
|
||||
版本文件、worktree、分支、PR/MR 和合并。普通发布优先走“更新说明 + annotated tag”的
|
||||
短路径；只有发布要求修改仓库内容时，才进入准备版本的分支流程。
|
||||
|
||||
## 安装
|
||||
|
||||
```bash
|
||||
pouch add manage-release # 当前项目
|
||||
pouch add manage-release -g # 全局
|
||||
```
|
||||
|
||||
## 使用前准备
|
||||
|
||||
- 项目已经是 Git 仓库，并配置了可访问的远端。
|
||||
- 项目已有版本来源或 tag 发布约定；没有时可以让 Agent 先给出版本建议。
|
||||
- 创建或合并 PR/MR、创建 Forge Release 时，准备好 GitHub、GitLab、Gitea 或 Forgejo
|
||||
对应的已认证 CLI。只发布 Git tag 时不要求 Forge CLI，但 Git remote 必须可读写。
|
||||
- 请求里写清目标版本、基线分支，以及允许执行到哪一步。没有明确授权的远端写操作
|
||||
不会执行。
|
||||
`manage-release` 已改名为 [releaser](../releaser/README.md)。本目录只是兼容占位，
|
||||
让旧项目里的 `.pouch.yaml`、已经装好的旧软链和旧说法不至于失效；真正的说明和流程都在
|
||||
`releaser/`。
|
||||
|
||||
## 使用示例
|
||||
|
||||
```text
|
||||
使用 manage-release，为已经合并到 main 的 1.6.0 发布 v1.6.0 tag。不要创建 Forge Release。
|
||||
使用 manage-release，为已经合并到 main 的 1.6.0 发布 v1.6.0 tag。
|
||||
```
|
||||
|
||||
## 常见用法
|
||||
Agent 命中后会立刻转到 `releaser`，按同一套规则执行。新请求建议直接用新名。
|
||||
|
||||
### 确定下一个版本号
|
||||
## 迁移
|
||||
|
||||
```text
|
||||
使用 manage-release 检查当前版本和这次改动，建议下一个版本号。只分析，不修改文件。
|
||||
```bash
|
||||
pouch add releaser # 新名，当前项目
|
||||
pouch add releaser -g # 新名，全局
|
||||
```
|
||||
|
||||
适合还没决定该发 patch、minor 还是 major 时使用。Agent 会读取项目版本规则、现有 tag
|
||||
和实际改动，给出建议及依据。
|
||||
|
||||
### 开始开发新版本
|
||||
|
||||
```text
|
||||
使用 manage-release，从 main 为 1.6.0 创建独立 worktree 和分支。先不要 push，也不要创建 PR。
|
||||
```
|
||||
|
||||
Agent 会检查已有 worktree、分支和 tag，确认没有冲突后准备开发目录。这个请求只授权
|
||||
本地操作。
|
||||
|
||||
### 把开发分支提交为 PR
|
||||
|
||||
```text
|
||||
使用 manage-release 检查当前分支，更新版本号和 CHANGELOG，运行项目测试，然后 push 并创建指向 main 的 PR。不要合并。
|
||||
```
|
||||
|
||||
适合开发已经完成，只需要整理版本信息并送审。Agent 会停在 PR 创建成功的位置，返回
|
||||
PR 地址、测试结果和待处理项。
|
||||
|
||||
### 合并通过检查的 PR
|
||||
|
||||
```text
|
||||
使用 manage-release 检查当前 PR。如果 CI、review 和冲突检查都通过，就按项目规则合并；不要打 tag。
|
||||
```
|
||||
|
||||
Agent 只会在仓库要求全部满足后合并，不会使用管理员权限绕过保护规则。合并完成后会
|
||||
返回准确的 merged commit。
|
||||
|
||||
### 为已合并版本发布 tag
|
||||
|
||||
```text
|
||||
使用 manage-release，为已经合并到 main 的 1.6.0 发布 v1.6.0 tag。根据 v1.5.0 到目标 commit 的实际变化生成更新说明，把说明写入 annotated tag，并验证远端 tag 的 commit 和说明。不要创建 Forge Release。
|
||||
```
|
||||
|
||||
这是无需修改仓库文件时的默认短路径，适合依靠 Git tag 触发后续 CI 发布的项目。Agent
|
||||
会分别验证目标 commit、更新说明和远端 tag，不会创建 worktree、发布分支或 PR，也不会
|
||||
给未合并分支打正式 tag。
|
||||
|
||||
### 为已合并版本创建 Gitea Release
|
||||
|
||||
```text
|
||||
使用 manage-release，发布已经合并到 main 的 1.6.0：生成更新说明，创建并验证附带说明的 v1.6.0 annotated tag，然后在 Gitea 创建使用同一份说明的 Release。
|
||||
```
|
||||
|
||||
Agent 会先证明 tag 已存在、指向计划 commit 且包含更新说明，再创建 Gitea Release。
|
||||
Release 创建失败时保留正确的 tag，从 Release 阶段恢复。
|
||||
|
||||
### 完成端到端发布
|
||||
|
||||
```text
|
||||
使用 manage-release 完成 1.6.0 发布：从 main 创建 worktree 和分支，完成版本更新和验证，创建 PR，检查通过后合并，推送 v1.6.0 tag，并创建 Forge Release。
|
||||
```
|
||||
|
||||
只有版本文件或仓库内 CHANGELOG 必须随发布修改时才使用这条长路径。tag 仍必须附带更新
|
||||
说明，Forge Release 复用同一份说明。遇到 review 未通过、CI 失败、版本冲突或已有同名
|
||||
tag 时，Agent 会停止并说明卡在哪一步，不会绕过检查继续发布。
|
||||
|
||||
### 发布紧急修复版本
|
||||
|
||||
```text
|
||||
使用 manage-release 从 main 准备 1.6.1 hotfix。创建独立 worktree，完成修复后开 PR；检查通过就合并并发布 v1.6.1。
|
||||
```
|
||||
|
||||
适合线上问题修复。Skill 仍走正常 PR 和保护分支流程，不会因为是 hotfix 就直接推送
|
||||
main 或覆盖已有 tag。
|
||||
|
||||
### 从中断位置继续
|
||||
|
||||
```text
|
||||
使用 manage-release 检查 v1.6.0 当前发布状态，从尚未完成的步骤继续。不要重复创建分支、PR、tag 或 release。
|
||||
```
|
||||
|
||||
适合合并后打 tag 失败、tag 已推送但 release 未创建，或者 Agent 会话中断的情况。
|
||||
Skill 会从 Git 和代码托管平台重新判断状态，再继续缺失的步骤。
|
||||
|
||||
## Agent 会做什么
|
||||
|
||||
Agent 会先发现项目自己的版本和发布规则、锁定远端目标 commit，再判断发布是否要求修改
|
||||
仓库内容。不需要修改时直接生成更新说明并发布 annotated tag；需要修改时才准备分支，
|
||||
并只在隔离用户工作确有必要时创建 worktree。它只执行请求中明确授权的阶段，并在合并、
|
||||
tag 或 release 条件不满足时停止。
|
||||
|
||||
## 如何判断完成
|
||||
|
||||
- 只分析版本时，结果包含建议版本及依据。
|
||||
- 创建开发环境时，结果包含 worktree 路径、分支和基线 commit。
|
||||
- 创建或合并 PR/MR 时，结果包含 URL、检查状态和 merged commit。
|
||||
- 发布 tag 时，远端 tag 解引用后的 commit 与目标 commit 一致，而且 tag object 包含经过
|
||||
核对的更新说明。
|
||||
- 创建 Forge Release 时，结果包含可访问的 release URL，正文与 tag 更新说明一致。
|
||||
- 中途停止时，结果说明停在哪一步、为什么停止，以及下次如何继续。
|
||||
|
||||
## 不适用的场景
|
||||
|
||||
普通功能开发、普通 worktree 或 PR/MR 操作、代码审查、构建 Docker 镜像或上传 DEB 包
|
||||
不需要触发 `manage-release`。只有任务明确涉及版本发布、发布分支、版本号、发布 PR/MR
|
||||
或 release tag 时，才交给这个 Skill。
|
||||
- 旧软链保持有效，不需要先删除。
|
||||
- 各项目 `.pouch.yaml` 里的 `manage-release` 可以分批改成 `releaser`。
|
||||
- 确认没有项目再按旧名启用后，删除本目录即可；它是纯占位，删除不丢内容。
|
||||
|
||||
+12
-232
@@ -1,239 +1,19 @@
|
||||
---
|
||||
name: manage-release
|
||||
description: >-
|
||||
管理 Git 项目从已准备 commit 到版本发布的生命周期：发现并遵循项目版本与发布策略，
|
||||
优先为远端已验证 commit 生成更新说明并创建 annotated release tag，按需创建 Forge
|
||||
Release；只有必须修改版本文件或仓库内发布说明时，才创建或复用版本分支、worktree
|
||||
和 PR/MR。也支持恢复中断流程与安全清理。用户要求发布版本、打 release tag、创建
|
||||
平台 Release、准备版本变更、处理 hotfix 或继续未完成发布时使用。只做普通编码、普通
|
||||
worktree 或 PR/MR 操作、代码审查、构建或上传 DEB/Docker 等产物、管理仓库权限时不使用。
|
||||
【已弃用，兼容占位】manage-release 已改名为 releaser。命中本 skill 时不要在此执行任何
|
||||
流程，直接读取 ../releaser/SKILL.md 并按其执行。发布版本、打 release tag、创建平台
|
||||
Release、准备版本变更、hotfix、继续未完成发布等请求都属于 releaser。
|
||||
---
|
||||
|
||||
# Manage Release
|
||||
# manage-release（已弃用）
|
||||
|
||||
根据项目现有规则管理源码版本生命周期。把项目策略当作规则来源，把 Git 与代码托管
|
||||
平台的实时状态当作运行状态；不要创建另一份会与分支、PR/MR 或 tag 分叉的状态文件。
|
||||
本 skill 已改名为 [releaser](../releaser/SKILL.md)。这里只是兼容占位，**没有流程内容**。
|
||||
|
||||
## 按需读取参考资料
|
||||
|
||||
- 开始任何流程时读取 [project-policy.md](references/project-policy.md)，确定策略来源和默认值。
|
||||
- 需要选择、更新或核对版本号，或生成 tag 更新说明时读取
|
||||
[versioning.md](references/versioning.md)。
|
||||
- 需要 push、创建或合并 PR/MR、创建 Forge Release 时读取
|
||||
[forge-adapters.md](references/forge-adapters.md)。
|
||||
- 遇到重复资源、并发冲突、部分成功或清理请求时读取
|
||||
[recovery.md](references/recovery.md)。
|
||||
- 仅当用户要求为项目固化发布规则时，复制并修改
|
||||
[release-policy.template.yaml](templates/release-policy.template.yaml)。不要在普通发布中自动添加配置。
|
||||
|
||||
## 授权边界
|
||||
|
||||
按用户明确要求执行到对应阶段：
|
||||
|
||||
- 分析版本或检查状态：只执行读取和计算，不修改文件或远端。
|
||||
- 开始或准备版本：允许创建本地分支、worktree，并修改版本文件。
|
||||
- push 或创建 PR/MR：仅在用户明确要求 push、提交 PR/MR 或执行完整发布时进行。
|
||||
- 合并和推送 tag：仅在用户明确要求相应动作或完整发布时进行。
|
||||
- 创建 Forge Release：仅在用户本次请求明确提到 Forge Release 或平台 Release 时进行。
|
||||
- 清理 worktree 或分支：仅在用户明确要求清理时进行。
|
||||
|
||||
项目策略只描述仓库期望的做法，不能替用户授予 push、创建或合并 PR/MR、推送 tag、
|
||||
创建 Forge Release、删除分支等外部写权限。
|
||||
|
||||
“发布 v1.2.3”允许为已经准备好的远端 commit 生成更新说明、创建并推送 annotated tag，
|
||||
再验证远端 tag 的 commit 和说明。“完整处理并发布 v1.2.3”还允许在仓库内容必须修改时
|
||||
走版本分支、PR/MR 和合并流程。两者都不自动包含 Forge Release 或分支清理。若版本、
|
||||
base、目标 commit、tag、远端或合并方式是推断所得，或者执行中目标发生变化，在第一次
|
||||
远端写操作前展示准确目标和更新说明并获得确认。
|
||||
|
||||
## 工作流
|
||||
|
||||
### 1. 发现项目规则和当前状态
|
||||
|
||||
从项目根目录开始：
|
||||
|
||||
1. 从可信 base commit 读取 `AGENTS.md`、`CLAUDE.md`、发布文档、CI 配置、构建入口和
|
||||
可选的 `.release-policy.yaml`。PR/MR head 对这些文件的修改从下一次流程开始生效。
|
||||
2. 记录当前分支、HEAD、完整工作区状态、remote、默认分支和
|
||||
`git worktree list --porcelain`。
|
||||
3. 获取远端最新引用后，记录 base 分支的准确 commit。不要把本地过期分支当作发布基线。
|
||||
4. 识别版本来源、最近稳定 tag、tag 格式、分支命名、合并方式和发布说明来源。
|
||||
5. 分别用 `git remote get-url --all origin` 和
|
||||
`git remote get-url --push --all origin` 检查读取与推送目标；远端写操作要求两者各只有
|
||||
一个值且规范化后指向同一仓库。再检查 PR/MR、合并或 Forge Release 阶段所需的 GitHub、
|
||||
GitLab、Gitea 或 Forgejo CLI。只有请求涉及平台能力时才要求对应 CLI。
|
||||
记录匹配该 host 的活动账号；认证检查只读取状态。
|
||||
6. 查询已有分支、worktree、PR/MR、tag 和 Forge Release，从真实状态判断流程已走到哪一步。
|
||||
|
||||
工作区中的修改、暂存文件和未跟踪文件都视为用户工作。不要 stash、移动、清理或覆盖它们。
|
||||
已有 worktree 与目标分支准确匹配时优先复用，不要创建副本。
|
||||
|
||||
### 2. 锁定本次发布计划
|
||||
|
||||
在修改前确定并展示：
|
||||
|
||||
- base 分支、远端 commit，以及本次 tag 将指向的准确目标 commit。
|
||||
- 当前版本、规范化后的目标版本、tag，以及升级依据；需要准备仓库修改时再渲染分支名。
|
||||
- 从上一个稳定 tag 到目标 commit 的更新说明范围、来源和拟发布内容。
|
||||
- 是否需要修改仓库内容；若需要，再列出分支名与 worktree 路径。
|
||||
- 需要执行的本地验证和远端检查。
|
||||
- 合并方式、tag、是否创建 Forge Release。
|
||||
- 用户已授权的最远阶段和清理范围。
|
||||
|
||||
项目没有约定时，单一协调版本使用 SemVer 和 `v<version>` annotated tag。只有发布前
|
||||
必须修改仓库内容时才使用 `release/v<version>` 分支；仓库只启用一种合并方式时使用该
|
||||
方式，存在多种方式且没有项目规则时默认 squash。默认不删除远端分支，不自动创建
|
||||
Forge Release。
|
||||
|
||||
把用户输入拆成“规范版本”和“展示名称”：默认 SemVer 的规范版本是无 `v` 前缀的
|
||||
`1.6.0`，版本文件和 `{version}` 都使用该值；分支与 tag 再分别按 pattern 渲染为
|
||||
`release/v1.6.0` 和 `v1.6.0`。用户输入 `v1.6.0` 时先规范化，不要产生双前缀。
|
||||
|
||||
### 3. 选择直接发布或准备版本
|
||||
|
||||
先计算发布所需的仓库内容差异，不要为了遵循固定模板而创建分支或 worktree。满足以下
|
||||
条件时走直接发布路径，跳过第 4 至 7 节：
|
||||
|
||||
- 目标 commit 已作为准确远端引用读取，并可从计划的 base 或项目允许的维护分支到达。
|
||||
- 项目权威版本文件若存在，目标 commit 中已经是目标版本；或项目明确以 tag 作为版本来源。
|
||||
- 项目不要求把本次 CHANGELOG 或发布说明提交回仓库。
|
||||
- 项目要求的构建、测试和发布检查已经通过。
|
||||
|
||||
直接发布不 checkout 目标 commit，不创建分支、worktree、版本提交或 PR/MR。更新说明是
|
||||
tag object 和可选 Forge Release 的内容，不因生成说明本身进入仓库修改路径。
|
||||
|
||||
只要版本文件、生成元数据或仓库内 CHANGELOG 必须修改，就进入准备版本路径。优先复用
|
||||
身份准确、未被占用且适合本次发布的现有分支；没有时才创建版本分支。优先复用安全且
|
||||
干净的现有 worktree；当前目录承载用户工作、目标分支已在别处使用或需要隔离时，才创建
|
||||
linked worktree。用户只授权了直接发布时，在展示必要差异后停止，不要擅自扩大到修改、
|
||||
分支或 PR/MR 流程。
|
||||
|
||||
### 4. 创建或复用准备版本的分支和 worktree
|
||||
|
||||
仅在第 3 节判定需要准备仓库修改时执行本节。优先使用当前环境提供的 worktree 管理器；
|
||||
项目仓库中的管理脚本只有在可信 base 已声明且经过检查时才能使用，没有时使用原生 Git。
|
||||
创建前验证：
|
||||
|
||||
- 目标分支和目录未被其他 worktree 占用。
|
||||
- 目标目录不是 `/`、用户主目录、仓库根目录或已有非空目录。
|
||||
- base 使用刚获取的远端引用，例如 `origin/main`，而不是不确定的新旧本地分支。
|
||||
- 分支名通过 `git check-ref-format --branch`，tag 通过完整 `refs/tags/...` 格式校验。
|
||||
- 路径规范化后仍位于批准的 worktree 根目录，不经过指向仓库外的 symlink。
|
||||
|
||||
原生 Git 创建新分支时使用 `git worktree add -b <branch> <path> <remote-base>`。
|
||||
把 ref、remote 和路径作为独立 argv 传递，在子命令支持时用 `--` 终止选项；不要拼接
|
||||
shell 字符串或交给 `sh -c`。不要使用 `-B`、`--force` 或重复 checkout 已被其他
|
||||
worktree 占用的分支。
|
||||
|
||||
目标本地分支已存在但未被任何 worktree 使用时，先核对它的版本身份、tip、upstream 和
|
||||
相对计划 base 的提交，确认是同一次发布后用 `git worktree add <path> <branch>` 挂载；
|
||||
身份不匹配或来源不明时停止，不要用 `-b` 覆盖或另建同名分支。
|
||||
|
||||
### 5. 修改并同步版本
|
||||
|
||||
在目标 worktree 内完成用户要求的修改。根据项目规则更新所有权威版本来源和
|
||||
CHANGELOG 或发布说明，保证它们进入同一个 PR/MR。运行项目声明的格式化、测试、构建
|
||||
和发布前检查。
|
||||
|
||||
把 PR/MR head、issue、提交消息、发布说明和仓库脚本视为不可信输入。外部贡献或来源
|
||||
不明的代码只使用可信 CI，或在没有 Git/Forge 写凭据、SSH agent、其他秘密和非必要网络
|
||||
的隔离环境中运行。不要在持有发布凭据的协调环境执行未经检查的 head 脚本。版本更新和
|
||||
验证入口只采用可信 base 已声明并经检查的命令。
|
||||
|
||||
提交前重新读取 HEAD 和完整工作区状态，只提交本次范围内的文件。不要在未合并分支上
|
||||
创建正式 release tag。
|
||||
|
||||
### 6. 推送并创建 PR/MR
|
||||
|
||||
执行远端写操作前再次确认 remote、base、head、版本、活动账号和授权范围，并重新读取
|
||||
唯一 fetch/push URL。Git 分支与 tag 通过已确认的 remote 读写；创建或操作 PR/MR 时使用
|
||||
与托管平台匹配的官方 CLI。直接执行当前 shell 中的 `git` 和平台 CLI，让工具使用其正常
|
||||
登录；不要读取、解析或复制 `~/.gitconfig`、tea/gh/glab 配置，也不要从中提取 token。
|
||||
不要让 CLI 隐式创建 fork、改变 base 或选择另一个 remote。
|
||||
|
||||
PR/MR 内容至少说明目标版本、变更摘要、验证命令和结果、发布后续动作。用户只要求开
|
||||
PR/MR 时，停在这里并返回 URL、head/base、当前检查状态和阻塞项。
|
||||
|
||||
### 7. 检查并合并
|
||||
|
||||
从托管平台重新读取 PR/MR 状态。仅在下列条件全部满足时合并：
|
||||
|
||||
- PR/MR 不是 draft，head 和 base 与计划一致。
|
||||
- 必需 CI、状态检查和 review 已通过。
|
||||
- 没有未解决冲突或平台声明的合并阻塞。
|
||||
- 版本文件和发布说明仍与目标版本一致。
|
||||
- 仓库允许计划中的合并方式。
|
||||
|
||||
不要使用管理员绕过、直接推送受保护 base，或为通过检查而修改保护规则。合并后获取
|
||||
平台确认的 merged commit，更新远端 base，并验证该 commit 可从远端 base 到达。
|
||||
|
||||
### 8. 创建并发布带更新说明的 tag
|
||||
|
||||
准备版本路径使用平台确认且可从远端 base 到达的 merged commit；直接发布路径使用计划
|
||||
中锁定且重新验证过的远端目标 commit。两者统一记为 release commit。核对目标版本后，
|
||||
再查询一次远端同名 tag。
|
||||
|
||||
创建 tag 前，按 [versioning.md](references/versioning.md) 生成并检查 tag message：根据
|
||||
上一个稳定 tag 到 release commit 的实际差异填写 `Summary`、`Changes`、`Validation`
|
||||
和 `Base commit`；首次发布则使用项目声明的发布基线，没有声明时核对完整可达历史并明确
|
||||
标记首次发布。空说明、只重复版本号或提交标题、缺少规定字段、模板占位文字、伪造变更
|
||||
或无法由实际变化支持的内容都不能发布。
|
||||
|
||||
tag 不存在时，把检查通过的完整 message 写入文件，再用
|
||||
`git tag -a <tag> <release-commit> -F <release-notes-file>` 创建 annotated tag；项目
|
||||
要求签名时，必须先确认签名工具和密钥可用，创建 signed annotated tag，并在本地验证签名
|
||||
成功后才允许 push。显式指定 release commit，并只推送这个 tag。禁止使用简短 `-m` 或
|
||||
创建 lightweight release tag。签名不可用或验证失败时停止，不得降级为 unsigned tag。
|
||||
|
||||
同名远端 tag 已存在且指向其他 commit 时立即停止。不要覆盖、删除或移动已经发布的
|
||||
tag。同名 tag 即使指向 release commit，只要它是 lightweight tag、缺少更新说明或说明与
|
||||
计划不一致，也视为身份不匹配并停止。推送后读取远端 tag object，确认它是 annotated
|
||||
tag，将它解引用到 commit 并核对完整更新说明；commit 和说明必须都与发布计划完全一致。
|
||||
|
||||
仅当用户本次请求明确要求时创建 Forge Release；项目策略只能说明创建方式，不能授予
|
||||
外部写权限。必须引用已经存在并验证过的 tag，禁止让平台从默认分支隐式创建 tag。
|
||||
Forge Release 正文复用 tag 中经过验证的更新说明，不维护第二份相互独立的发布内容。
|
||||
|
||||
### 9. 验证、恢复和清理
|
||||
|
||||
分别报告以下状态，不要用“发布成功”掩盖其中某一步未完成：
|
||||
|
||||
- 版本文件和本地验证。
|
||||
- PR/MR URL、合并状态和 merged commit。
|
||||
- 远端 tag 的对象类型、完整更新说明及其解引用后的 commit。
|
||||
- Forge Release URL、可见性及正文一致性，若本次要求创建。
|
||||
- worktree、本地分支和远端分支是否保留。
|
||||
|
||||
清理时只移除干净且已确认不再使用的 linked worktree，不使用强制删除。删除本地或远端
|
||||
分支前确认其提交已合并且可从 base 或 tag 到达；本地和远端分支删除都必须有明确授权。
|
||||
|
||||
## 硬停止条件
|
||||
|
||||
遇到以下任一情况时停止相应写操作并说明恢复路径：
|
||||
|
||||
- base、目标版本、版本来源、remote，或请求阶段所需的托管平台无法唯一确定。
|
||||
- 直接发布的目标 commit 无法从计划远端分支到达，或项目要求的发布检查未通过。
|
||||
- 项目策略包含未知字段、错误类型、仓库外路径或不安全 ref。
|
||||
- 多个权威版本来源不一致。
|
||||
- 目标分支、worktree、PR/MR、tag 或 release 已存在但身份不匹配。
|
||||
- required checks、review 或冲突状态不满足合并规则。
|
||||
- 合并结果的准确 commit 无法从平台确认，或无法从远端 base 到达。
|
||||
- 远端 tag 已指向其他 commit。
|
||||
- 更新说明为空、只有版本号或提交标题、缺少规定字段、包含占位内容、无法追溯到实际
|
||||
变化，或远端 tag 不是包含计划说明的 annotated tag。
|
||||
- 请求的 PR/MR、合并或 Forge Release 阶段所需的平台 CLI 缺失、未认证或无法读取状态。
|
||||
- 项目要求 tag 签名，但签名能力不可用或本地签名验证失败。
|
||||
- 操作需要 force push、管理员绕过、移动已发布 tag 或覆盖用户工作。
|
||||
- 不可信代码只能在带仓库写凭据、SSH agent、秘密或非必要网络的环境中运行。
|
||||
|
||||
不要在命令参数、文件、提交、PR/MR、日志或最终回复中暴露 token、密码、私钥路径或
|
||||
认证配置。CLI 不可用时给出人工交接信息，不要擅自改用带 token 的 `curl`。
|
||||
|
||||
## 完成标准
|
||||
|
||||
只分析时，给出当前状态、建议版本、依据和下一步。直接发布时，给出目标 commit 和更新
|
||||
说明，不得虚构 worktree 或分支步骤。开始准备版本时，给出所用 worktree、分支和基线
|
||||
commit；未新建 worktree 时明确说明复用了哪个安全工作区。创建 PR/MR 时，给出 URL 与
|
||||
检查状态。合并时，给出 merged commit。发布 tag 时，证明远端 tag 是包含计划更新说明的
|
||||
annotated tag，并解引用到 release commit。创建 Forge Release 时，再给出 release URL、
|
||||
可见性与正文一致性。任何部分未完成都要标明阻塞阶段和可恢复动作。
|
||||
- 用户提到 `manage-release`、`/manage-release` 或 `$manage-release` 时：读取
|
||||
[../releaser/SKILL.md](../releaser/SKILL.md)，按其内容与授权边界执行，不要在本目录
|
||||
里寻找步骤、references 或 templates。
|
||||
- 本目录不保留 `references/` 和 `templates/`，正文只有一份，在 `releaser/`。
|
||||
- 旧项目 `.pouch.yaml` 里仍写 `manage-release` 也能正常安装，软链不会悬空；方便时改成
|
||||
`releaser`。
|
||||
- 确认没有项目再按旧名启用后，可以直接删除本目录。
|
||||
|
||||
@@ -1,83 +0,0 @@
|
||||
# 代码托管平台适配
|
||||
|
||||
## 区分 Git 与 Forge 能力
|
||||
|
||||
fetch、查询 remote refs、推送分支和推送单个 tag 属于 Git transport 能力，可直接通过
|
||||
已配置的 Git remote 完成。创建或查看 PR/MR、合并以及创建 Forge Release 才需要平台
|
||||
CLI。只发布 tag 时，不要因为缺少 Forge CLI 而停止；仍要验证 remote、认证目标和推送
|
||||
授权，并在 push 后读回远端 ref。
|
||||
|
||||
## 选择 Forge 适配器
|
||||
|
||||
从 push remote URL 识别平台，并使用对应官方 CLI：
|
||||
|
||||
| 平台 | CLI | PR/MR 命令域 | Release 命令域 |
|
||||
|---|---|---|---|
|
||||
| GitHub | `gh` | `gh pr` | `gh release` |
|
||||
| GitLab | `glab` | `glab mr` | `glab release` |
|
||||
| Gitea / Forgejo | `tea` | `tea pulls` | `tea releases` |
|
||||
|
||||
先运行 CLI 的版本、认证状态和只读查看命令。记录匹配 remote host 的活动账号；存在多
|
||||
个账号或 profile 时，必须唯一确定本次使用的身份。CLI 版本之间的 flags 可能不同，
|
||||
每次执行写操作前读取对应子命令的 `--help`，不要凭记忆拼接参数。
|
||||
|
||||
直接从目标 worktree 的当前 shell 运行 `git` 与平台 CLI，让它们使用各自正常的登录机制。
|
||||
Gitea/Forgejo 使用 `tea whoami` 和 `tea` 对应子命令；不要由 Agent 读取 tea 配置文件、
|
||||
调用 credential helper 导出 token，或把 token 转存到命令参数、环境文件和发布说明。
|
||||
|
||||
当请求确实涉及 PR/MR、合并或 Forge Release，且 remote host 无法识别、CLI 缺失、认证
|
||||
失败或 CLI 指向另一个实例时，停止对应平台阶段并报告：
|
||||
|
||||
- host、owner/repository、remote 名称。
|
||||
- base、head 和当前 commit。
|
||||
- 已完成的本地验证。
|
||||
- 尚需人工执行的创建 PR/MR、合并或 release 步骤。
|
||||
|
||||
不要自动安装 CLI，也不要把 token 放进命令行后改用 `curl`。用户明确提供受支持的其他
|
||||
集成时，可以使用该集成，但仍遵守同一套授权和验证闸门。
|
||||
|
||||
## 创建 PR/MR
|
||||
|
||||
使用显式的 repository、base、head、title 和 body，避免交互式默认值改变目标。把动态
|
||||
值作为独立 argv 或结构化输入传递，不拼接 shell 命令。创建前：
|
||||
|
||||
1. 确认当前分支已经推送到计划中的 remote。
|
||||
2. 查询同一 head/base 是否已有 open PR/MR，有则复用并更新状态，不重复创建。
|
||||
3. 确认 head commit 与本地已验证 commit 相同。
|
||||
4. 确认 CLI 不会隐式创建 fork 或推送到另一个 remote。
|
||||
5. 再次读取活动账号，向用户展示 host、repository、账号和授权的最远阶段。
|
||||
|
||||
PR/MR body 包含目标版本、变更摘要、验证命令与结果、发布后续。创建后读取平台返回的
|
||||
URL、编号、head/base 和状态，不以命令退出码代替远端读回。
|
||||
|
||||
## 检查和合并
|
||||
|
||||
用结构化输出读取 draft、head commit、base、review、required checks、冲突或
|
||||
mergeability、允许的合并方式。平台字段缺失时，使用平台提供的只读详情命令补足；不能
|
||||
证明闸门通过时保持未合并。
|
||||
|
||||
GitHub 使用 `gh pr view`、`gh pr checks` 和 `gh pr merge`；GitLab 使用
|
||||
`glab mr view`、pipeline 状态和 `glab mr merge`；Gitea 或 Forgejo 使用
|
||||
`tea pulls` 的查看、检查和合并能力。实际参数以当前 CLI 的 `--help` 为准。
|
||||
|
||||
若用户要求检查通过后自动合并，优先使用仓库已经启用的 auto-merge 或 merge queue。
|
||||
不要用管理员选项绕过 review、CI、conversation resolution 或 protected branch。
|
||||
|
||||
合并后重新读取 PR/MR，取得平台确认的 merged commit。随后 fetch 远端 base，并验证该
|
||||
commit 已进入远端 base。只看到本地 merge commit 或分支关闭不足以证明平台已合并。
|
||||
|
||||
## 创建 Forge Release
|
||||
|
||||
把 Git tag 和 Forge Release 当成两个独立状态。先创建、推送并验证包含完整更新说明的
|
||||
annotated tag，再创建 release。Forge Release 正文复用已经冻结并验证的 tag 更新说明，
|
||||
不要重新生成另一份内容。
|
||||
|
||||
- GitHub 创建 release 时使用能够拒绝缺失 tag 的选项，例如当前 CLI 支持的
|
||||
`--verify-tag`。
|
||||
- GitLab、Gitea 或 Forgejo 创建 release 前，先用只读命令证明 tag 已存在并指向计划的
|
||||
commit、tag object 包含计划的更新说明；不要使用会顺便创建 tag 的默认行为。
|
||||
- 预发布版本按项目规则标记 prerelease，不要自动把它标为 latest 或 stable。
|
||||
- 发布后重新读取 release URL、tag、正文和可见性，确认正文与 tag 更新说明一致。
|
||||
|
||||
Forge Release 创建失败但 tag 已成功推送时，保留 tag 并从 release 阶段恢复，不要重新
|
||||
合并或创建另一个 tag。
|
||||
@@ -1,77 +0,0 @@
|
||||
# 项目发布策略
|
||||
|
||||
## 策略优先级
|
||||
|
||||
按以下顺序确定规则，并在来源冲突时停止说明，不要静默覆盖：
|
||||
|
||||
1. 用户本次请求中明确给出的目标和授权范围。
|
||||
2. 项目 `AGENTS.md`、`CLAUDE.md`、发布文档和可选的 `.release-policy.yaml`。
|
||||
3. 构建脚本、包清单、CI 工作流和历史发布使用的实际入口。
|
||||
4. 代码托管平台当前的默认分支、保护规则、检查和允许的合并方式。
|
||||
5. 本 Skill 的默认值。
|
||||
|
||||
用户请求若与项目硬规则或平台保护冲突，展示冲突并请求处理方式。不要借用户的一句
|
||||
“直接发布”绕过仓库声明的检查或保护。
|
||||
|
||||
开始流程时记录 base commit，并读取该提交对应的项目策略。本次发布分支对策略文件的
|
||||
修改不应改变正在执行的流程；新策略从下一次发布开始生效。
|
||||
|
||||
项目策略不能授予外部写权限。即使配置声明创建 Forge Release 或删除远端分支，也必须
|
||||
由用户本次请求明确授权相应动作。
|
||||
|
||||
## 可选配置
|
||||
|
||||
项目反复出现同一种歧义时，用户可以要求创建 `.release-policy.yaml`。从
|
||||
`templates/release-policy.template.yaml` 复制后，只保留项目真正需要固定的字段。
|
||||
|
||||
配置只保存可提交的项目策略：
|
||||
|
||||
- `schema`：配置结构版本，当前为 `1`。
|
||||
- `base_branch`：发布 PR/MR 的目标分支。
|
||||
- `branch_pattern`：需要准备仓库修改时使用的版本分支格式，支持无展示前缀的规范
|
||||
`{version}`；直接发布不因此创建分支。
|
||||
- `version.scheme`：`semver` 或项目已经使用的其他方案。
|
||||
- `version.sources`：构建和运行实际读取的权威版本文件；项目明确从 Git tag 派生版本时
|
||||
可以省略，不要为了发布新增无消费方的版本文件。
|
||||
- `tag_pattern`：release tag 格式，支持无展示前缀的规范 `{version}`。
|
||||
- `merge_method`：`squash`、`merge` 或 `rebase`。
|
||||
- `forge_release`：项目是否建议在 tag 后创建 Forge Release；它不授予创建权限。
|
||||
- `tag_signing`：`off`、`optional` 或 `required`。
|
||||
- `delete_remote_branch`：发布完成后是否建议清理远端源分支；它只是计划偏好，不是删除
|
||||
权限或自动执行指令，仍需用户在本次请求中明确授权。
|
||||
|
||||
不要在配置中保存 token、账号、私钥路径、个人工作目录或一次性发布状态。不要加入任意
|
||||
shell 命令字段；本地验证继续从项目文档、CI 和构建入口发现。
|
||||
|
||||
读取配置后校验字段集合、类型和枚举值，遇到未知字段时停止。`branch_pattern` 和
|
||||
`tag_pattern` 展开后分别用 Git branch/tag ref 规则校验；不要把配置值拼进 shell 字符串。
|
||||
`version.sources` 中每一项必须是仓库相对路径，拒绝绝对路径和 `..`。规范化并解析
|
||||
symlink 后，目标必须仍在当前 worktree 内；权威来源通常还应由 Git 跟踪。
|
||||
|
||||
先按版本方案把用户输入规范化。默认 SemVer 接受 `1.6.0` 或作为用户输入的 `v1.6.0`，
|
||||
但内部 `{version}` 固定为 `1.6.0`；版本文件写入规范值，branch/tag pattern 分别负责添加
|
||||
展示前缀。自定义版本方案按项目文档定义规范值，不能从 pattern 猜测后重复添加前缀。
|
||||
|
||||
## 无配置时的发现顺序
|
||||
|
||||
1. 从 remote HEAD 和平台信息确定默认 base，不能确定时询问。
|
||||
2. 从项目文档、CI 和构建入口找版本文件及更新方式。
|
||||
3. 仅当发布需要修改仓库内容时，从已有分支和已合并 PR/MR 识别命名与合并方式。
|
||||
4. 从稳定 tag 识别前缀、版本方案和更新说明范围；项目由 tag 派生版本时，把实际构建
|
||||
入口和 tag 历史共同作为版本来源证据，否则只把 tag 当作交叉验证。
|
||||
5. 无项目约定时使用 SemVer 和 `v<version>` annotated tag；需要准备仓库修改时再使用
|
||||
`release/v<version>` 和 squash merge。默认不创建 Forge Release，不删除远端分支。
|
||||
|
||||
## 每次执行的计划快照
|
||||
|
||||
在第一次写操作前列出以下事实：
|
||||
|
||||
- base 分支、远端 commit 和 tag 将指向的目标 commit。
|
||||
- 当前版本、目标版本、版本来源和升级依据。
|
||||
- 更新说明的提交范围、来源和拟发布内容。
|
||||
- 是否需要修改仓库内容；需要时再列出 worktree 路径与分支名。
|
||||
- PR/MR 托管平台和合并方式。
|
||||
- tag 与 Forge Release 计划。
|
||||
- 用户授权的最远阶段和清理范围。
|
||||
|
||||
任何事实在执行中改变时刷新计划。改变会影响已授权的远端写目标时，再次获得确认。
|
||||
@@ -1,55 +0,0 @@
|
||||
# 中断恢复与安全清理
|
||||
|
||||
## 恢复原则
|
||||
|
||||
每次重入都从 Git 和代码托管平台读取状态，不依赖上一轮聊天结论。先记录准确的
|
||||
base、head、PR/MR、merged commit、tag 和 release，再执行唯一缺失的下一步。
|
||||
|
||||
网络或平台调用返回超时、未知状态或非结构化错误时，先用只读命令刷新远端状态。不要把
|
||||
重试当成默认动作；创建 PR/MR、合并、推 tag 和创建 release 都可能已经成功。
|
||||
|
||||
## 常见部分状态
|
||||
|
||||
| 当前状态 | 继续方式 | 禁止事项 |
|
||||
|---|---|---|
|
||||
| 远端 release commit 已准备，没有 tag | 核对版本与更新说明后直接创建 annotated tag | 不创建无必要的分支或 worktree |
|
||||
| 本地 annotated tag 已创建但未推送 | 核对对象类型、commit 和完整说明后只推送该 tag | 不因重入重复创建或改写 tag |
|
||||
| worktree 已创建，无改动 | 继续开发，或经授权移除干净 worktree | 不使用强制删除 |
|
||||
| 本地发布分支已存在，没有 worktree | 核对版本身份、tip、upstream 和 base 后挂载现有分支 | 不用 `-b` 覆盖分支 |
|
||||
| 分支已推送，没有 PR/MR | 确认 head/base 后创建一次 PR/MR | 不重复推送新分支 |
|
||||
| PR/MR 已存在，未合并 | 复用 URL，刷新 checks、review 和冲突状态 | 不创建第二个 PR/MR |
|
||||
| PR/MR 已合并，没有 tag | 获取 merged commit，生成并确认更新说明后继续发布 | 不重新合并 |
|
||||
| tag 已推送，没有 release | 验证 tag 的 commit 和更新说明后创建 Forge Release | 不创建替代 tag |
|
||||
| tag 指向正确 commit 但为 lightweight 或说明不符 | 停止并交由维护者决定撤销或发布修订版本 | 不移动、覆盖或补写远端 tag |
|
||||
| release 已创建，验证未完成 | 读回 release、tag 和可见性 | 不直接声称发布完成 |
|
||||
| 同名资源身份不匹配 | 停止并报告差异 | 不覆盖、关闭或删除未知资源 |
|
||||
|
||||
## 并发冲突
|
||||
|
||||
两个 Agent 或维护者可能同时准备相同版本。创建分支、PR/MR、tag 或 release 前都重新查询
|
||||
目标是否存在。推 tag 前立即检查远端引用；push 因同名引用失败时保持失败，不要 force。
|
||||
|
||||
base 在开发期间前进时，让 PR/MR 和仓库规则决定是否需要更新分支。已经推送的发布分支
|
||||
不在本 Skill 中重写历史；需要更新时优先创建普通提交，或交给平台的 update branch、
|
||||
merge queue 和 auto-merge。任何 force push 都是硬停止条件。
|
||||
|
||||
## 回滚边界
|
||||
|
||||
- 未推送的本地版本提交可以在用户授权下修改或放弃，但不要覆盖其他工作。
|
||||
- 已推送但未合并的 PR/MR 可以关闭，分支默认保留。
|
||||
- 已合并变更通过新的 revert PR/MR 回滚，不重写 base 历史。
|
||||
- 已发布 tag 默认不可变。commit 或更新说明错误时停止，由维护者决定撤销发布或发布新版本。
|
||||
- Forge Release 失败不回滚已经正确推送的 tag；从 release 阶段恢复。
|
||||
|
||||
## 清理规则
|
||||
|
||||
清理始终放在发布验证之后：
|
||||
|
||||
1. 确认 worktree 没有修改、暂存或未跟踪文件。
|
||||
2. 确认分支提交已从远端 base 或已验证 tag 到达。
|
||||
3. 仅移除目标 linked worktree，不操作主 worktree，不使用 `--force`。
|
||||
4. 删除本地分支前再次确认已合并。
|
||||
5. 删除本地或远端分支都必须有用户本次请求的明确授权；项目策略不能代替授权。
|
||||
6. 使用 `git worktree prune --dry-run` 查看陈旧记录；不要把 prune 当作普通清理步骤。
|
||||
|
||||
任何清理条件不满足时保留现场，并报告路径、分支、未提交状态和后续人工动作。
|
||||
@@ -1,132 +0,0 @@
|
||||
# 版本号与 tag
|
||||
|
||||
## 确定权威版本来源
|
||||
|
||||
按项目实际构建链路寻找版本来源，不要遍历到一个看起来像版本号的字符串就修改。优先级：
|
||||
|
||||
1. 项目发布文档或 `.release-policy.yaml` 明确声明的文件。
|
||||
2. 项目明确由 Git tag 或 VCS metadata 派生构建版本时，以 tag 规则作为发布版本来源，
|
||||
不要为了发布凭空新增或修改版本文件。
|
||||
3. 构建、打包或运行入口直接读取的清单，例如 `VERSION`、`package.json`、
|
||||
`pyproject.toml`、`Cargo.toml` 或语言工具链的版本配置。
|
||||
4. 由权威文件生成的镜像文件、锁文件或发布元数据。
|
||||
5. 最近稳定 tag，用于确定当前已发布版本、更新说明范围和发布历史。
|
||||
|
||||
记录每个权威文件的当前值和更新方式。多个权威来源不一致时停止，不要选择修改时间最新
|
||||
的文件，也不要只改其中一个。
|
||||
|
||||
配置声明了版本文件时，它们必须使用仓库相对路径。拒绝绝对路径、`..` 和解析后逃出目标
|
||||
worktree 的 symlink；修改前确认规范化后的准确路径。不要用 glob 或模糊搜索结果执行
|
||||
批量替换。
|
||||
|
||||
## 选择目标版本
|
||||
|
||||
项目已有 CalVer、单调构建号、独立包版本或自定义方案时继续使用，不要迁移到 SemVer。
|
||||
项目没有规则且只有一个协调版本时使用 SemVer：
|
||||
|
||||
- 不兼容的公开 API 或行为变化增加 major。
|
||||
- 向后兼容的新功能增加 minor。
|
||||
- 向后兼容的修复增加 patch。
|
||||
|
||||
根据实际兼容性判断，不要只凭 commit 前缀自动升级。项目明确采用 Conventional Commits
|
||||
或已有版本工具时，可以把它们的结果作为项目规则。破坏性影响无法确定时给出建议并请
|
||||
用户确定准确版本。
|
||||
|
||||
预发布版本沿用项目格式；没有格式时使用 `-alpha.N`、`-beta.N` 或 `-rc.N`。正式 tag
|
||||
默认不加入 build metadata。不要从带 build metadata 的 tag 推断兼容性顺序。
|
||||
|
||||
独立多包版本、多个维护分支和 release train 不属于默认单版本流程。无法确定一个目标
|
||||
版本时停止并说明需要增加包或发布线维度。
|
||||
|
||||
## 规范化与渲染
|
||||
|
||||
内部始终分别记录规范版本、分支名和 tag 名。默认 SemVer 的规范版本不含 `v`，例如
|
||||
用户输入 `v1.6.0` 时规范化为 `1.6.0`；版本文件写入 `1.6.0`，再将它代入
|
||||
`release/v{version}` 和 `v{version}`。不要把完整 tag 名直接代入 `{version}`。
|
||||
|
||||
项目采用自定义前缀或非 SemVer 时，以项目版本来源定义规范值，以 branch/tag pattern
|
||||
定义展示形式。规范化结果无法唯一确定时停止并让用户确认。
|
||||
|
||||
## 判断是否需要同步版本
|
||||
|
||||
直接读取计划 release commit 中的权威版本来源。版本文件已经是目标值，或者项目明确由
|
||||
tag 派生版本，且发布说明不要求写回仓库时，不产生仓库修改，直接进入 tag 发布。
|
||||
|
||||
只有权威版本文件、生成文件或仓库内 CHANGELOG 必须变化时，才进入准备版本流程并使用
|
||||
分支/PR。不要为了制造发布提交而触碰与构建、运行或项目发布规则无关的文件。
|
||||
|
||||
## 同步版本
|
||||
|
||||
仅在判断存在必要仓库差异后，在准备版本的分支中一次性更新所有权威版本来源、生成文件
|
||||
和项目要求的 CHANGELOG。运行项目自己的版本更新工具时，先检查它会修改哪些文件，避免
|
||||
隐式发布、提交或上传。
|
||||
|
||||
提交前确认：
|
||||
|
||||
- 所有权威来源都是目标版本。
|
||||
- 生成文件与来源一致。
|
||||
- CHANGELOG 或发布说明描述的是本次实际变更。
|
||||
- 项目构建和测试读取到了新版本。
|
||||
|
||||
## 生成更新说明
|
||||
|
||||
以最近一个适用于当前发布线的稳定 tag 为起点，以 release commit 为终点，结合项目
|
||||
CHANGELOG、已合并 PR/MR 和实际 diff 生成更新说明。首次发布使用项目声明的发布基线；
|
||||
没有声明时核对完整可达历史，并在说明中明确这是首次发布。
|
||||
|
||||
正式版本的 tag message 使用以下固定格式；内容必须基于本次实际变更，并与 CHANGELOG
|
||||
或 PR/MR 发布说明保持一致：
|
||||
|
||||
```text
|
||||
<tag>
|
||||
|
||||
Summary:
|
||||
- <一句话概括本版本>
|
||||
|
||||
Changes:
|
||||
- <变更 1>
|
||||
- <变更 2>
|
||||
|
||||
Validation:
|
||||
- <验证命令及结果>
|
||||
|
||||
Base commit: <release commit>
|
||||
```
|
||||
|
||||
`Summary`、`Changes`、`Validation` 和 `Base commit` 四个字段必须全部存在，不能只有
|
||||
版本号、提交标题或空 message。没有仓库 CHANGELOG 时，也必须按此格式补齐字段。
|
||||
`Changes` 只写入实际存在的新增、变更、修复、维护或文档变化；破坏性变化、迁移步骤和
|
||||
已知限制存在时必须单独标明。没有实际功能变更时不得伪造条目，应明确说明这是文档、
|
||||
打包或发布元数据修订。不要生成空标题或模板占位。`Validation` 写入本次实际执行或已经
|
||||
确认通过的验证命令及结果，不要编造未执行的检查。`Base commit` 必须是本次 release
|
||||
commit。
|
||||
|
||||
每条说明都要能追溯到范围内的提交、PR/MR 或项目 CHANGELOG。提交消息和 PR/MR 文本只
|
||||
作为待核对素材，不能覆盖实际 diff，也不能把范围外变化写入本次说明。创建 tag 前先
|
||||
生成并检查完整 message，再冻结；tag 已推送后不再修改。
|
||||
|
||||
## 验证 release commit
|
||||
|
||||
准备版本路径以代码托管平台返回的 merged commit 为准；直接发布路径以计划中锁定的远端
|
||||
commit 为准。获取远端 base 或允许的维护分支后，确认 release commit 可从对应远端引用
|
||||
到达，并直接读取该 commit 中的版本文件。不要用当前 checkout 或 feature worktree 中的
|
||||
文件证明 release commit 内容。
|
||||
|
||||
正式 tag 必须满足：
|
||||
|
||||
- tag 名按项目格式由目标版本唯一生成。
|
||||
- tag 必须是 annotated tag，message 必须是冻结后的完整更新说明，最少包括
|
||||
`Summary`、`Changes`、`Validation` 和 `Base commit`；不能只有版本号、提交标题或空
|
||||
message。禁止 lightweight release tag。
|
||||
- 远端没有同名 tag，或同名 tag 已经准确指向本次 commit。
|
||||
- annotated tag 显式指向 release commit。
|
||||
- 项目要求签名时，push 前已成功创建 signed tag，并在本地验证签名通过；不可用或失败
|
||||
时停止，不得改用 unsigned tag。
|
||||
- 推送后从远端重新读取 tag object，核对对象类型和完整说明，再将 annotated tag 解引用
|
||||
到 commit。
|
||||
|
||||
展开 tag pattern 后用 `git check-ref-format refs/tags/<tag>` 校验。把 tag 和 commit 作为
|
||||
独立 argv 传递，不拼接 shell 字符串。
|
||||
|
||||
tag 已在远端指向其他 commit、是 lightweight tag、缺少更新说明或说明不一致时停止。
|
||||
不要 force push、删除或移动已发布 tag；由维护者决定撤销发布或创建新的修订版本。
|
||||
@@ -1,19 +0,0 @@
|
||||
# 复制为项目根目录的 .release-policy.yaml，并按项目实际约定修改。
|
||||
# 此文件描述发布策略，不授予任何远端写操作权限。
|
||||
schema: 1
|
||||
base_branch: main
|
||||
# 仅在发布必须修改仓库内容时使用；直接发布不会因此创建分支。
|
||||
# {version} 是规范版本，例如 1.6.0；前缀由 pattern 添加。
|
||||
branch_pattern: release/v{version}
|
||||
version:
|
||||
scheme: semver
|
||||
# 项目明确从 Git tag 派生版本时可以省略 sources。
|
||||
sources:
|
||||
- VERSION
|
||||
tag_pattern: v{version}
|
||||
merge_method: squash
|
||||
# 只表示项目偏好；创建 Forge Release 仍需用户本次请求明确授权。
|
||||
forge_release: false
|
||||
tag_signing: optional
|
||||
# 只表示清理偏好；删除仍需用户在本次请求中明确授权。
|
||||
delete_remote_branch: false
|
||||
Reference in New Issue
Block a user