[Gu-ZT]

更新 dev/1.21.8 的发布操作说明，与默认分支总控 #255 配套。

输入 tag 直接决定 Git 标签、JAR 和 Maven 版本，不添加 v 前缀。总控使用 -Pmod_version=<tag> 覆盖本分支构建版本，无需预先同步 gradle.properties；预发布不升 patch，纯 X.Y.Z 发布后创建下一 patch 的 PR。普通开发 CI 保持 Beta。

本 PR 仅修改 RELEASING.md；版本覆盖由默认分支总控统一传入，本分支现有 Gradle 配置无需改动。已核对本分支 CI 的 Beta 配置，git diff --check 通过。

[Gugle2308]

结论：新增段落的目标状态与 #255 的设计一致，且「预发布不升 patch」「开发 CI 上架 Beta」两条在当前默认分支上已为真；但「必填 tag 输入框」「-Pmod_version 覆盖」「无需同步 gradle.properties」三项依赖仍未合并的 #255，与当前默认分支的实际行为相反——照此操作会在 dispatch 后立刻撞上 Branches disagree on mod_version 硬失败。

审查范围：base dev/1.21.8 → head de2d1cf2，1 文件 +2/−0（纯文档，与 1.21.1 线 #256 全文一致）、draft=false、mergeable=true、无既有 review、无代码改动。

🔴 一、三条操作说明与当前默认分支相反（依赖 #255）

本轮复核 dev/26.1 实况（#255 仍是 open / merged=false）：

# dev/26.1/.github/workflows/release.yml
on.workflow_dispatch.inputs:            # ← 只有 generate_release_notes / dry_run
                                        # ← 没有 tag 输入

# dev/26.1/.github/release/release.py
versions[line] = mod_version(props)                                  # 版本取自各分支
require(len(set(versions.values())) == 1,
        f"Branches disagree on mod_version: {versions}")             # ← 七线必须一致，硬失败
plan = {"tag": "v" + version, …}                                     # ← tag 带 v

逐条对照：

文档声称	当前 dev/26.1 实际	结论
「在必填的 tag 输入框填写发布版本」	工作流没有 tag 输入	❌ 不存在
「不加 v 前缀」	当前恒为 "v" + version	❌ 相反
「总控通过 -Pmod_version=<tag> 覆盖」	全仓无该参数	❌ 不存在
「不要求预先修改或同步 gradle.properties」	恰好要求：Branches disagree on mod_version 直接中断预检	❌ 相反（后果最重）
「生成的 Git tag、JAR 和 Maven 版本均使用输入值」	tag = v + 分支版本	❌ 相反

建议：#255 先合、本族的文档 PR 后合；若必须先合，请在文档里加「以下流程需默认分支总控 #255 合并后生效；当前请先同步七条分支的 mod_version」，避免误导操作者。

✅ 二、已验证为真的部分

声称	证据
「Create Multi-Version Releases」入口存在	dev/26.1 的 release.yml 首行已是该名称（#252 已合并）
「上述预发布不升 patch，纯 X.Y.Z 发布后创建下一 patch 的 PR」	默认分支已有 bump_patch 输出 + job 级 if + bump() 内 if "+" in version: return ✓
「普通开发 CI 仍上架 Beta 快照」	本分支实测：build_and_test.yml:103 Upload Beta snapshot to Modrinth and CurseForge，:117 version-type: beta ✓
「仅修改 RELEASING.md」	patch-diff 1 文件 +2/−0 ✓
与同族一致	与 #256（1.21.1）全文逐字节相同 ✓

💡 三、其余建议

1. 同族共 6 条文档 PR（我列了当前全部）：#256(1.21.1)、#258(1.21.8)、#257(1.21.4)、#259(1.21.11)、#260(26.2)、#261(26.3)，加上 #255 自身更新 dev/26.1 的 RELEASING.md。七条线的这段文案完全相同，因此 §一 的合并顺序要求对六条都适用；若 §一 需要加一句"待 #255 生效"的说明，六条必须同时加，否则又会不一致。
2. 措辞可更精确：「生成的 Git tag…使用输入值」——tag 实际指向锁定的 dev/26.1 提交（不是本分支头），可加「（指向本次锁定的默认分支提交）」。
3. 「上述预发布」指代略松：上述 回指例子 2.0.0+pre-release.13，改为「+ 后缀版本不升 patch」与表格口径更一致。

验证边界

默认分支与七条线的文件内容经 raw.githubusercontent.com/<branch>/<path> 实读，#255 与 #256/#257/#258/#259/#260/#261 的状态经 API 核实；与 #255 代码的一致性结论来自上轮对其 patch-diff 的逐行核对（#255 仍未合并，内容可能再变）。未执行发布流程，未跑 actionlint。