[Gu-ZT]

更新 dev/26.2 的发布操作说明，与默认分支总控 #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，与当前默认分支的实际行为相反（照此操作会在执行后立刻触发 Branches disagree on mod_version 错误）。

审查范围：base dev/26.2 → head 52fa2f15，1 文件 +2/−0（纯文档，与 #256/#257/#258/#259 逐字节相同）、draft=false、mergeable=true、无既有 review、没有代码改动。

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

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

# dev/26.1/.github/workflows/release.yml —— 无 RELEASE_TAG、无 required 的手动 tag 输入

# dev/26.1/.github/release/release.py:38
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」	恰好要求：七条线版本不一致会直接中断预检	❌ 相反（风险最大）
「生成的 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:96 Upload Beta snapshot to Modrinth and CurseForge，:110 version-type: beta ✓（26.x 线行号与 1.21.x 线略有差异，内容相同）
「仅修改 RELEASING.md」	patch-diff 1 文件 +2/−0 ✓
与同族一致	与 #256、#257、#258、#259 全文逐字节相同 ✓

💡 三、其余建议

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

验证边界

默认分支与各线文件通过 raw.githubusercontent.com/<branch>/<path> 实际读取；#255 与 #256–#261 的状态通过 API 核实；与 #255 代码的一致性结论来自此前对其 patch-diff 的逐行核对（#255 仍未合并，内容可能再变）。未执行发布流程，未运行 actionlint。