[Gu-ZT]

更新 dev/1.21.1 的发布操作说明，与默认分支总控 #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，在当前默认分支上与实际行为相反；若本 PR 先合，会给出会导致预检硬性失败的错误操作指引。

审查范围：base dev/1.21.1 → head 1326bc98，1 文件 +2/−0（纯文档）、draft=false、mergeable=true、无既有 review、无代码改动。

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

我直接查了 dev/26.1 的实况：

# https://raw.githubusercontent.com/.../dev/26.1/.github/workflows/release.yml
on:
  workflow_dispatch:
    inputs:
      generate_release_notes:   # ← 只有这两项
      dry_run:                  # ← 没有 tag

# https://raw.githubusercontent.com/.../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}")             # ← 七线必须一致，硬失败
version = versions[ANCHOR]
plan = {"repo": repo(), "tag": "v" + version, "version": version, …} # ← tag 带 v

而 #255 当前仍是 state: open / merged: false（我核了 API）。逐条对照本 PR 新增段落：

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

其中第四条后果最重：读者照本分支文档跳过 gradle.properties 同步，会在 dispatch 后立刻撞上 Branches disagree on mod_version 硬失败。

建议：#255 先合、本 PR 后合（或同批且本 PR 在后）；若必须先合此文档，请加一句「以下流程需默认分支总控 #255 合并后生效；当前请先同步七条分支的 mod_version」。

✅ 二、已验证为真的部分

声称	证据
「Create Multi-Version Releases」入口存在	dev/26.1 的 release.yml 首行已是 name: Create Multi-Version Releases（#252 已合并，2026-11-10T07:28Z）
「上述预发布不升 patch，纯 X.Y.Z 发布后创建下一 patch 的 PR」	默认分支已有 output("bump_patch", str("+" not in plan["version"]).lower())、bump() 里 if "+" in version: … return、job 级 if: needs.prepare.outputs.bump_patch == 'true' ✓
「普通开发 CI 仍上架 Beta 快照」	本分支实测：.github/workflows/build_and_test.yml:97 Upload Beta snapshot to Modrinth and CurseForge，:111 version-type: beta ✓
「本分支仅改 RELEASING.md」	patch-diff 仅 1 文件、+2/−0 ✓
目标状态与 #255 设计一致	上一轮我已逐条核对 #255 的 tag 必填输入、-Pmod_version=$RELEASE_VERSION、prepare() 删除七线版本一致性校验 ✓

💡 三、其余建议

1. 其余六条线的文档存在同步空缺：我逐线查了 RELEASING.md 中 -Pmod_version 的出现次数——1.21.1/1.21.4/1.21.8/1.21.11/26.1/26.2/26.3 全部为 0。本 PR 只补 1.21.1，dev/26.1 由 #255 补；#255 合并后仍需为另外五条线（1.21.4/1.21.8/1.21.11/26.2/26.3）各补一份，否则同族文档再次不一致。建议在 PR 描述里列出这条后续清单。
2. 措辞可更精确：「生成的 Git tag、JAR 和 Maven 版本均使用输入值」——tag 实际指向锁定的 dev/26.1 提交（不是本分支头），本分支文档无需展开，但可加「（指向本次锁定的默认分支提交）」以免读者以为 tag 打在本分支上。
3. 「上述预发布」指代略松：上述 回指的是例子 2.0.0+pre-release.13，可改为「+ 后缀版本不升 patch」，与表格口径一致。

验证边界

默认分支与七条线的文件内容均通过 raw.githubusercontent.com/<branch>/<path> 实读（#255 状态经 API 核实）；文档声称与 #255 代码的一致性结论来自上一轮对 #255 patch-diff 的逐行核对（#255 仍未合并，内容可能再变）。未执行任何发布流程，未运行 actionlint。