桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载MooTool 是一个同一仓库、多个独立产品线的 monorepoJava 版、Electron 版、Tauri 版与原生 macOS 版各自维护版本号、发布节奏和更新通道。本文基于仓库根目录的发布约定文档 RELEASE_CONVENTIONS.md结合update-manifest.json、GitHub Actions 工作流与发布校验脚本scripts/manage_releases.py的实际实现完整讲解 MooTool 的多产品版本隔离方案——读完你可以理解Git tag 前缀如何充当产品边界、全局Latest为什么只能属于一个产品、CI 如何用一份 Python 脚本做跨产品的版本一致性校验以及客户端更新检查为什么只读取自己产品节点的清单。1. 为什么需要这份约定MooTool 仓库里同时存在多条产品线产品目录技术栈状态以仓库现状为准根目录src/JavaSwingpom.xml当前版本 1.8.7历史产品持续维护next/Electron Vite React TypeScriptnext/package.json当前版本 1.3.2当前主力产品next-tauri/Tauri 2 Rust ReactRelease candidate0.1.0-rc 系列next-macos-native/Swift 原生VERSION文件当前为 0.8.0公开预发布这些产品版本号互相独立Java 的1.8.7、Electron 的1.3.2、原生 macOS 的0.8.0可以在同一仓库中并存互不干扰。但这带来一个工程问题Git tag 在整个仓库内是全局命名空间v1.0.0只能指向一个提交。约定文档给出的答案是——用 tag 前缀做产品隔离并且产品线由 tag、Release、安装包名称、应用 ID 和更新清单共同隔离不依赖长期分叉的产品分支。文档第 1 节确立了五条基本原则Java、Electron 及未来的 Tauri、原生 macOS 实现是不同产品线各自维护版本号和发布节奏产品版本遵循语义化版本SemVer例如1.0.0、1.1.0、2.0.0-beta.1不同产品可以同时拥有相同版本号Git tag 在仓库内必须唯一因此除历史 Java 产品线外tag 必须带稳定的产品 ID 前缀产品线由 tag、Release、安装包名称、应用 ID 和更新清单共同隔离已发布的 tag 和 Release 不得改指向其他提交也不得被另一个产品复用。2. 产品与 tag 命名规则约定文档第 2 节定义了核心映射表产品 ID、版本来源与 tag 前缀一一对应产品 ID产品版本来源Git tagRelease 标题示例javaMooTool Javapom.xml、UiConsts.APP_VERSION、version_summary.jsonv{version}MooTool Java 1.7.10next-electronMooTool Next Electronnext/package.jsonnext-electron-v{version}MooTool Next Electron 1.0.0next-tauriMooTool Next Tauri启用产品时确定next-tauri-v{version}MooTool Next Tauri 1.0.0next-macos-nativeMooTool Next macOS Nativenext-macos-native/VERSIONnext-macos-native-v{version}MooTool Next macOS Native 1.0.0tag 命名示例v1.7.9 # Java 1.7.9 v1.8.0 # Java 1.8.0 next-electron-v1.0.0 # Electron 1.0.0 next-electron-v1.1.0 # Electron 1.1.0 next-electron-v2.0.0-beta.1 # Electron 2.0.0 beta 1 next-tauri-v1.0.0 # Tauri 1.0.0为什么 Java 保留无前缀的v*文档明确解释历史 Java tagv1.0.0至v1.7.9保持不变v*命名空间保留给 Java新产品不得使用无产品前缀的 tag除非单独评审和迁移否则不把 Java 改为java-v*以免破坏历史连续性和现有自动化。这一点在仓库中可以验证——src/main/resources/version_summary.json的versionIndex里完整保留了从v1.0.0到v1.8.7的连续历史版本序列任何改名都会让历史客户端的版本索引失效。版本来源在源码中的落点约定中的版本来源不是抽象说法每个来源都对应仓库中的具体文件且会被 CI 逐一核对Java 产品pom.xml 的version当前1.8.7、UiConsts.java 中的APP_VERSION v1.8.7供关于对话框展示以及 version_summary.json 的currentVersion字段Electron 产品next/package.json 的version字段当前1.3.2原生 macOS 产品next-macos-native/VERSION 单行文件当前0.8.0。3. GitHub Release 约定每个 tag 对应一个且仅一个产品版本的 GitHub Release。文档第 3 节的规则逐条如下Release 标题必须包含完整产品名和版本号不能只写v1.0.0Release 正文开头必须说明产品线并注明它是否替代其他实现Release 只上传当前产品的安装包和更新元数据不混入其他产品的产物安装包文件名必须包含产品名、版本、操作系统和架构同一平台存在多种包型时还必须包含包型Electron 的 Linux 产物同时有AppImage与deb两种包型文件名以packageType区分;GitHub 自动生成的源码压缩包包含整个仓库这是 monorepo 的预期行为面向普通用户的下载入口应指向 Release 安装包而非源码包Release Notes 只能比较同一产品线的前后两个 tag不能把另一产品的最近 tag 当作上一个版本——这是 monorepo 下使用 GitHub 默认compare 自动生成 changelog功能最容易踩的坑版本说明有唯一的人工维护来源Electron 以next/release-notes/{version}.md为准当前仓库中已有1.0.0.md至1.3.2.md的完整序列GitHub Release 和update-manifest.json均从该文件生成Java 以src/main/resources/version_summary.json为准GitHub Release 从当前版本节点生成三语要求Release 正文必须依次包含 English、中文、日本語三部分。Java 当前版本节点必须提供title/log、titleEn/logEn、titleJa/logJa六个字段Electron 的版本 Markdown 必须直接维护完整三语内容。文档建议在 Release 正文顶部使用这样的说明 产品线MooTool Next Electron 版本1.0.0 本版本与 MooTool Java 独立安装、独立更新不会覆盖 Java 版本。源码级佐证三语与版本一致性不是建议而是 CI 硬校验这些规则由 scripts/manage_releases.py 在 CI 中以代码形式强制实施validate_multilingual_release_notes会检查 Release notes 中## English、## 中文、## 日本語三个标题存在且顺序正确否则直接抛错终止流水线electron_release_info要求next/package.json的版本拼出的next-electron-v{version}与 tag 完全一致且next/release-notes/{version}.md的第一行必须是# MooTool Next Electron {version}、正文不超过 5000 字符java_release_info则做四重校验pom.xml版本、UiConsts.APP_VERSION值、version_summary.json的currentVersion与versionIndex条目、以及六个三语字段全部非空——任何一处不一致都会导致 Java 发布失败由于 Java 的历史更新协议没有预发布通道脚本对 Java 版本显式拒绝 SemVer 预发布号MooTool Java prereleases are not supported by the legacy stable update feed脚本生成的 Java Release 正文会自动附加一行产品边界声明This release updates MooTool Java only; it does not replace or upgrade MooTool Next Electron.中文、日本語同理从机制上保证注明是否替代其他实现这条规则不会遗漏。4.Latest与下载入口GitHub 仓库只有一个全局LatestRelease无法设置Latest Java和Latest Electron并存。文档第 4 节的解决方案Latest表示当前推荐给新用户的主力稳定产品而不是所有产品中数值最大的版本当前主力产品为 MooTool Next Electron稳定的 Electron Release 可以设为LatestJava 及其他非主力产品发布时不得覆盖全局Latest自动化中应显式使用等价于make_latest: false的设置beta、rc 等测试版本必须标记为 pre-release不得设为LatestREADME 和官网应分别提供各产品的最新版本入口不以仓库级/releases/latest代替产品更新清单。这条约定在 CI 中有精确的执行点。build-installers.ymlJava 发布流水线在发布 Release 时硬编码了make_latest: false——也就是说 Java 版本无论发什么版本都不会抢占全局Latest而 next-build-installers.ymlElectron 流水线由manage_releases.py输出make_latest稳定版为true预发布版为false。两者组合后全局Latest事实上只会被 Electron 稳定版占据与文档中当前主力产品的定义一致。从源码结构看客户端侧也不依赖这个全局LatestElectron 的 updateService.ts 中parseManifest只从update-manifest.json的products[productId]节点取数据并强制要求schemaVersion 1且产品status为active版本比较用内置的 SemVercompareVersions完成而不是拉取 GitHub 的Latest接口。此外文档还规定Java 发布工具只接受稳定版v{major}.{minor}.{patch}需要测试 Java 安装包时使用手动 CI 工件workflow_dispatch 的release_tag输入项即为此设计不创建会被稳定客户端发现的预发布版本Electron 则支持 SemVer 预发布并由客户端自动隔离稳定与预发布更新。若未来主力实现发生变化应先修改本文件和下载入口再调整哪个产品可以更新全局Latest。5. 分支策略产品线不是分支线文档第 5 节的立场很明确——默认分支同时保存所有产品目录、公共资源、文档和 CI 配置日常开发使用当前主干与短期功能分支需要维护旧版本时可创建短期或维护型分支例如release/java-1.x但发布身份仍由产品 tag 决定不由分支决定不为 Java 和 Electron 维护永久互不合并的两套主分支避免公共文档、资源和自动化长期漂移同一提交可以被不同产品的 tag 引用但每个 tag 只发布对应产品的产物。这一策略的直接收益体现在发布脚本与 CI 配置这类公共资产上scripts/manage_releases.py、scripts/generate_download_links.py被 Java 和 Electron 两条流水线共同调用README 中的产品对照表链接到本约定文档也只需要一份。如果按产品拆分成互不合并的主分支这些公共逻辑就会复制出多份并各自漂移。6. CI 隔离与校验tag 前缀即产品边界发布工作流必须通过 tag 前缀触发而不是根据整个仓库的最高版本判断产品。文档给出的触发规则表与当前.github/workflows/目录下的实际文件一一对应工作流tag 触发规则发布内容.github/workflows/build-installers.ymlv*MooTool Java.github/workflows/next-build-installers.ymlnext-electron-v*MooTool Next Electron.github/workflows/next-macos-native-build.ymlnext-macos-native-v*MooTool Next macOS NativeUniversal DMG Pre-releasemake_latest: false仓库中实际还存在next-tauri-ci.yml、next-tauri-release.yml、next-tauri-promote-update.yml等 Tauri 产品的工作流遵循同样的next-tauri-v*前缀隔离思路约定文档写于 Tauri 产品启用产品时确定版本来源之前具体触发规则以对应工作流文件为准。每条发布流水线至少完成六步校验从 tag 中解析产品 ID 和版本号校验 tag 版本与该产品的版本来源完全一致只构建、测试和收集当前产品目录的产物校验产物文件名、操作系统、架构和包型没有冲突或缺失创建或更新当前 tag 对应的 Release并按约定处理 pre-release 和Latest从当前产品的版本说明来源生成 Release Notes不调用可能跨产品比较 tag 的默认自动说明。普通提交或 Pull Request 可以使用目录过滤例如next-macos-native-build.yml对next-macos-native/**路径做了paths过滤以减少无关构建但正式发布必须以 tag 前缀作为最终产品边界。以 Electron 流水线为例其preparejob 的执行顺序完整体现了上述校验链npm ci→npm run check跑测试→ 调用python -u scripts/manage_releases.py validate-electron --tag ...校验 tag 与next/package.json一致性并产出version/title/prerelease/make_latest等输出→ 再额外执行python -m unittest scripts.test_manage_releases对发布工具自身做回归测试。随后矩阵构建 macOS Apple Silicon / macOS Intel / Windows x64 / Linux x64 四个平台产物Java 流水线则额外在发布前用manage_releases.py validate-java渲染三语 Release Notes并在资产就绪后回写download_links.json到 master 分支。7. 更新通道隔离这是整套约定中让用户感知不到 monorepo的关键层。文档第 7 节的隔离规则Java继续使用version_summary.json和download_links.json保证历史客户端兼容Electron使用根目录 update-manifest.json 中的next-electron节点未来产品必须在update-manifest.json使用自己的产品 ID不得读取或写入其他产品节点各客户端只能比较自身产品节点中的版本不能用 GitHub 仓库的全局Latest判断更新应用 ID、产品名和用户数据目录也应按产品隔离保证不同实现可以同时安装Electron 客户端使用独立应用 IDcom.rememberber.mootool.next.electron详见 next/doc/update-products-and-assets.mdElectron 稳定版客户端忽略prerelease版本beta/rc 客户端可以继续接收后续预发布版本并在正式版发布后升级到正式版Java 使用versionIndex判断版本先后及汇总中间版本说明不使用字符串比较版本号。update-manifest.json的实际结构印证了这套设计顶层是schemaVersion: 1加一个products注册表其中java节点为status: legacy且只保留指向version_summary.json的updateFeedUrl供旧协议兼容next-electron为status: active并维护完整的releases数组当前含 1.0.0 起 27 个稳定版本每条带prerelease标志、releaseUrl与按平台/架构/包型组织的assets每个资产带sha512与sizenext-tauri节点已有两个 rc 预发布版本0.1.0-rc.1、0.1.0-rc.2next-macos-native节点状态为 planned。客户端侧的隔离逻辑可以在 updateService.ts 中逐行验证parseManifest会拒绝未注册、非 active 或版本重复的产品节点版本筛选逻辑为allowPrerelease 当前版本含 prerelease 段 ? 允许 : 只接受稳定版再在合格版本中取 SemVer 最大者与当前版本比较后才提示更新——这正是文档所述客户端自动隔离稳定与预发布更新的实现。Electron 的清单格式、资产选择和自动下载细节见 next/doc/update-products-and-assets.md该文档开头也明确声明仓库级版本号、Git tag、Release、Latest和 CI 隔离规则以本约定文档为准它只补充客户端更新清单与安装包选择的实现细节。8. 发布顺序正式发布按以下顺序执行文档第 8 节更新目标产品的版本来源、变更说明和必要文档并完成测试创建符合命名规则的 tagCI 校验版本一致性构建安装包和自动更新元数据由流水线核对平台、架构、签名状态、文件名和更新元数据所有目标校验通过后发布 Release并按产品角色设置 pre-release 和LatestRelease 资产可访问后再更新并启用该产品的更新清单验证 README 下载入口、客户端更新检查和安装流程。顺序中有一条安全红线不要在 Release 资产尚未可用时提前向已发布客户端暴露新版本以免客户端发现版本后无法下载。这对更新清单类产品尤其重要——update-manifest.json中一旦出现某版本的releases条目所有该产品的客户端在下次检查时就会认为存在新版本如果对应的 Release 资产不可用更新流程将直接指向 404。关于签名文档明确当前 Electron 产品线允许未签名发布流水线必须标注这一状态但不得因缺少证书而阻止 Release。这与 CI 实现一致——next-build-installers.yml中有一个Report unsigned release mode步骤推送 tag 触发时输出 warningThis workflow intentionally publishes unsigned Electron packages. macOS updates download a verified DMG in the background, then require manual installation. 未签名 macOS 客户端可以在后台下载并校验 DMG完成后提示用户打开 DMG 并按常规方式拖入应用程序但不得调用应用内自动安装具体限制见 next/doc/update-products-and-assets.md 的未签名发布策略一节。9. Electron 首个正式版本两个1.0.0如何共存文档第 9 节对 Electron 产品的起始版本做了显式钉死应用版本1.0.0 Git tagnext-electron-v1.0.0 Release 标题MooTool Next Electron 1.0.0该版本不占用、不删除、不重建历史 Java tagv1.0.0也不表示 Java 版本升级为 2.0.0——两个1.0.0属于不同产品线可以在同一仓库中独立存在。这条规则回答了多产品 monorepo 最常见的疑问新产品的 1.0.0 和老产品的 1.0.0 会不会冲突不会因为二者的 tagnext-electron-v1.0.0vsv1.0.0、Release 标题、安装包文件名、应用 ID 和更新清单节点全部不同update-manifest.json中next-electron的 releases 数组也确实以1.0.0为第一个稳定版本起步。10. 小结约定文档 清单文件 CI 脚本的三层闭环回顾整份 RELEASE_CONVENTIONS.md它的可执行性来自三层机制的互相咬合命名层tag 前缀 产品 ID产品 ID 更新清单节点键、应用 ID 前缀、安装包命名前缀一个标识贯穿所有发布面校验层scripts/manage_releases.py 把tag 与版本来源一致三语 notes 完整预发布不得抢 Latest等规则从文档约定升级为 CI 失败条件消费层客户端如 updateService.ts与清单文件update-manifest.json只认自己的产品节点Java 历史客户端继续走version_summary.jsondownload_links.json旧协议。对维护者而言日常只需记住三步改自己产品的版本来源文件、按前缀规则打 tag、让 CI 完成其余校验对扩展者而言接入新产品线的模板也很清晰——新增next-xxx-v*tag 前缀、专属工作流、update-manifest.json产品节点和独立应用 ID即可在不触碰其他产品的前提下加入这套多产品发布体系。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐GenOffice架构解析6个Electron应用如何共享一套引擎层Monorepo完整指南GenOffice架构解析6个Electron应用如何共享一套引擎层Monorepo完整指南 GenOffice 是一个免费开源的 AI 办公套件支持编人工智能AI 应用桌面应用AI AgentMCP 服务AI 技能shadPS4 0.7.0 一启动就崩这份 Windows 11 排障指南帮你 4 步救回 PS4 游戏shadPS4 0.7.0 一启动就崩这份 Windows 11 排障指南帮你 4 步救回 PS4 游戏 昨天例行升级我把 shadPS4 刷到了最新的 0虚拟化图形学终极指南如何使用Mise在同一台机器上管理多个Tuist版本终极指南如何使用Mise在同一台机器上管理多个Tuist版本 在iOS开发过程中不同项目可能需要不同版本的Tuist工具来确保兼容性和稳定性。Tuist作为开发工具CLI后端云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/14 16:31:19 · 阅读 1.2k MooTool 多产品发布约定：一个 monorepo 里 Java、Electron 与 Tauri 如何共用同一套版本号体系
桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载MooTool 是一个同一仓库、多个独立产品线的 monorepoJava 版、Electron 版、Tauri 版与原生 macOS 版各自维护版本号、发布节奏和更新通道。本文基于仓库根目录的发布约定文档 RELEASE_CONVENTIONS.md结合update-manifest.json、GitHub Actions 工作流与发布校验脚本scripts/manage_releases.py的实际实现完整讲解 MooTool 的多产品版本隔离方案——读完你可以理解Git tag 前缀如何充当产品边界、全局Latest为什么只能属于一个产品、CI 如何用一份 Python 脚本做跨产品的版本一致性校验以及客户端更新检查为什么只读取自己产品节点的清单。1. 为什么需要这份约定MooTool 仓库里同时存在多条产品线产品目录技术栈状态以仓库现状为准根目录src/JavaSwingpom.xml当前版本 1.8.7历史产品持续维护next/Electron Vite React TypeScriptnext/package.json当前版本 1.3.2当前主力产品next-tauri/Tauri 2 Rust ReactRelease candidate0.1.0-rc 系列next-macos-native/Swift 原生VERSION文件当前为 0.8.0公开预发布这些产品版本号互相独立Java 的1.8.7、Electron 的1.3.2、原生 macOS 的0.8.0可以在同一仓库中并存互不干扰。但这带来一个工程问题Git tag 在整个仓库内是全局命名空间v1.0.0只能指向一个提交。约定文档给出的答案是——用 tag 前缀做产品隔离并且产品线由 tag、Release、安装包名称、应用 ID 和更新清单共同隔离不依赖长期分叉的产品分支。文档第 1 节确立了五条基本原则Java、Electron 及未来的 Tauri、原生 macOS 实现是不同产品线各自维护版本号和发布节奏产品版本遵循语义化版本SemVer例如1.0.0、1.1.0、2.0.0-beta.1不同产品可以同时拥有相同版本号Git tag 在仓库内必须唯一因此除历史 Java 产品线外tag 必须带稳定的产品 ID 前缀产品线由 tag、Release、安装包名称、应用 ID 和更新清单共同隔离已发布的 tag 和 Release 不得改指向其他提交也不得被另一个产品复用。2. 产品与 tag 命名规则约定文档第 2 节定义了核心映射表产品 ID、版本来源与 tag 前缀一一对应产品 ID产品版本来源Git tagRelease 标题示例javaMooTool Javapom.xml、UiConsts.APP_VERSION、version_summary.jsonv{version}MooTool Java 1.7.10next-electronMooTool Next Electronnext/package.jsonnext-electron-v{version}MooTool Next Electron 1.0.0next-tauriMooTool Next Tauri启用产品时确定next-tauri-v{version}MooTool Next Tauri 1.0.0next-macos-nativeMooTool Next macOS Nativenext-macos-native/VERSIONnext-macos-native-v{version}MooTool Next macOS Native 1.0.0tag 命名示例v1.7.9 # Java 1.7.9 v1.8.0 # Java 1.8.0 next-electron-v1.0.0 # Electron 1.0.0 next-electron-v1.1.0 # Electron 1.1.0 next-electron-v2.0.0-beta.1 # Electron 2.0.0 beta 1 next-tauri-v1.0.0 # Tauri 1.0.0为什么 Java 保留无前缀的v*文档明确解释历史 Java tagv1.0.0至v1.7.9保持不变v*命名空间保留给 Java新产品不得使用无产品前缀的 tag除非单独评审和迁移否则不把 Java 改为java-v*以免破坏历史连续性和现有自动化。这一点在仓库中可以验证——src/main/resources/version_summary.json的versionIndex里完整保留了从v1.0.0到v1.8.7的连续历史版本序列任何改名都会让历史客户端的版本索引失效。版本来源在源码中的落点约定中的版本来源不是抽象说法每个来源都对应仓库中的具体文件且会被 CI 逐一核对Java 产品pom.xml 的version当前1.8.7、UiConsts.java 中的APP_VERSION v1.8.7供关于对话框展示以及 version_summary.json 的currentVersion字段Electron 产品next/package.json 的version字段当前1.3.2原生 macOS 产品next-macos-native/VERSION 单行文件当前0.8.0。3. GitHub Release 约定每个 tag 对应一个且仅一个产品版本的 GitHub Release。文档第 3 节的规则逐条如下Release 标题必须包含完整产品名和版本号不能只写v1.0.0Release 正文开头必须说明产品线并注明它是否替代其他实现Release 只上传当前产品的安装包和更新元数据不混入其他产品的产物安装包文件名必须包含产品名、版本、操作系统和架构同一平台存在多种包型时还必须包含包型Electron 的 Linux 产物同时有AppImage与deb两种包型文件名以packageType区分;GitHub 自动生成的源码压缩包包含整个仓库这是 monorepo 的预期行为面向普通用户的下载入口应指向 Release 安装包而非源码包Release Notes 只能比较同一产品线的前后两个 tag不能把另一产品的最近 tag 当作上一个版本——这是 monorepo 下使用 GitHub 默认compare 自动生成 changelog功能最容易踩的坑版本说明有唯一的人工维护来源Electron 以next/release-notes/{version}.md为准当前仓库中已有1.0.0.md至1.3.2.md的完整序列GitHub Release 和update-manifest.json均从该文件生成Java 以src/main/resources/version_summary.json为准GitHub Release 从当前版本节点生成三语要求Release 正文必须依次包含 English、中文、日本語三部分。Java 当前版本节点必须提供title/log、titleEn/logEn、titleJa/logJa六个字段Electron 的版本 Markdown 必须直接维护完整三语内容。文档建议在 Release 正文顶部使用这样的说明 产品线MooTool Next Electron 版本1.0.0 本版本与 MooTool Java 独立安装、独立更新不会覆盖 Java 版本。源码级佐证三语与版本一致性不是建议而是 CI 硬校验这些规则由 scripts/manage_releases.py 在 CI 中以代码形式强制实施validate_multilingual_release_notes会检查 Release notes 中## English、## 中文、## 日本語三个标题存在且顺序正确否则直接抛错终止流水线electron_release_info要求next/package.json的版本拼出的next-electron-v{version}与 tag 完全一致且next/release-notes/{version}.md的第一行必须是# MooTool Next Electron {version}、正文不超过 5000 字符java_release_info则做四重校验pom.xml版本、UiConsts.APP_VERSION值、version_summary.json的currentVersion与versionIndex条目、以及六个三语字段全部非空——任何一处不一致都会导致 Java 发布失败由于 Java 的历史更新协议没有预发布通道脚本对 Java 版本显式拒绝 SemVer 预发布号MooTool Java prereleases are not supported by the legacy stable update feed脚本生成的 Java Release 正文会自动附加一行产品边界声明This release updates MooTool Java only; it does not replace or upgrade MooTool Next Electron.中文、日本語同理从机制上保证注明是否替代其他实现这条规则不会遗漏。4.Latest与下载入口GitHub 仓库只有一个全局LatestRelease无法设置Latest Java和Latest Electron并存。文档第 4 节的解决方案Latest表示当前推荐给新用户的主力稳定产品而不是所有产品中数值最大的版本当前主力产品为 MooTool Next Electron稳定的 Electron Release 可以设为LatestJava 及其他非主力产品发布时不得覆盖全局Latest自动化中应显式使用等价于make_latest: false的设置beta、rc 等测试版本必须标记为 pre-release不得设为LatestREADME 和官网应分别提供各产品的最新版本入口不以仓库级/releases/latest代替产品更新清单。这条约定在 CI 中有精确的执行点。build-installers.ymlJava 发布流水线在发布 Release 时硬编码了make_latest: false——也就是说 Java 版本无论发什么版本都不会抢占全局Latest而 next-build-installers.ymlElectron 流水线由manage_releases.py输出make_latest稳定版为true预发布版为false。两者组合后全局Latest事实上只会被 Electron 稳定版占据与文档中当前主力产品的定义一致。从源码结构看客户端侧也不依赖这个全局LatestElectron 的 updateService.ts 中parseManifest只从update-manifest.json的products[productId]节点取数据并强制要求schemaVersion 1且产品status为active版本比较用内置的 SemVercompareVersions完成而不是拉取 GitHub 的Latest接口。此外文档还规定Java 发布工具只接受稳定版v{major}.{minor}.{patch}需要测试 Java 安装包时使用手动 CI 工件workflow_dispatch 的release_tag输入项即为此设计不创建会被稳定客户端发现的预发布版本Electron 则支持 SemVer 预发布并由客户端自动隔离稳定与预发布更新。若未来主力实现发生变化应先修改本文件和下载入口再调整哪个产品可以更新全局Latest。5. 分支策略产品线不是分支线文档第 5 节的立场很明确——默认分支同时保存所有产品目录、公共资源、文档和 CI 配置日常开发使用当前主干与短期功能分支需要维护旧版本时可创建短期或维护型分支例如release/java-1.x但发布身份仍由产品 tag 决定不由分支决定不为 Java 和 Electron 维护永久互不合并的两套主分支避免公共文档、资源和自动化长期漂移同一提交可以被不同产品的 tag 引用但每个 tag 只发布对应产品的产物。这一策略的直接收益体现在发布脚本与 CI 配置这类公共资产上scripts/manage_releases.py、scripts/generate_download_links.py被 Java 和 Electron 两条流水线共同调用README 中的产品对照表链接到本约定文档也只需要一份。如果按产品拆分成互不合并的主分支这些公共逻辑就会复制出多份并各自漂移。6. CI 隔离与校验tag 前缀即产品边界发布工作流必须通过 tag 前缀触发而不是根据整个仓库的最高版本判断产品。文档给出的触发规则表与当前.github/workflows/目录下的实际文件一一对应工作流tag 触发规则发布内容.github/workflows/build-installers.ymlv*MooTool Java.github/workflows/next-build-installers.ymlnext-electron-v*MooTool Next Electron.github/workflows/next-macos-native-build.ymlnext-macos-native-v*MooTool Next macOS NativeUniversal DMG Pre-releasemake_latest: false仓库中实际还存在next-tauri-ci.yml、next-tauri-release.yml、next-tauri-promote-update.yml等 Tauri 产品的工作流遵循同样的next-tauri-v*前缀隔离思路约定文档写于 Tauri 产品启用产品时确定版本来源之前具体触发规则以对应工作流文件为准。每条发布流水线至少完成六步校验从 tag 中解析产品 ID 和版本号校验 tag 版本与该产品的版本来源完全一致只构建、测试和收集当前产品目录的产物校验产物文件名、操作系统、架构和包型没有冲突或缺失创建或更新当前 tag 对应的 Release并按约定处理 pre-release 和Latest从当前产品的版本说明来源生成 Release Notes不调用可能跨产品比较 tag 的默认自动说明。普通提交或 Pull Request 可以使用目录过滤例如next-macos-native-build.yml对next-macos-native/**路径做了paths过滤以减少无关构建但正式发布必须以 tag 前缀作为最终产品边界。以 Electron 流水线为例其preparejob 的执行顺序完整体现了上述校验链npm ci→npm run check跑测试→ 调用python -u scripts/manage_releases.py validate-electron --tag ...校验 tag 与next/package.json一致性并产出version/title/prerelease/make_latest等输出→ 再额外执行python -m unittest scripts.test_manage_releases对发布工具自身做回归测试。随后矩阵构建 macOS Apple Silicon / macOS Intel / Windows x64 / Linux x64 四个平台产物Java 流水线则额外在发布前用manage_releases.py validate-java渲染三语 Release Notes并在资产就绪后回写download_links.json到 master 分支。7. 更新通道隔离这是整套约定中让用户感知不到 monorepo的关键层。文档第 7 节的隔离规则Java继续使用version_summary.json和download_links.json保证历史客户端兼容Electron使用根目录 update-manifest.json 中的next-electron节点未来产品必须在update-manifest.json使用自己的产品 ID不得读取或写入其他产品节点各客户端只能比较自身产品节点中的版本不能用 GitHub 仓库的全局Latest判断更新应用 ID、产品名和用户数据目录也应按产品隔离保证不同实现可以同时安装Electron 客户端使用独立应用 IDcom.rememberber.mootool.next.electron详见 next/doc/update-products-and-assets.mdElectron 稳定版客户端忽略prerelease版本beta/rc 客户端可以继续接收后续预发布版本并在正式版发布后升级到正式版Java 使用versionIndex判断版本先后及汇总中间版本说明不使用字符串比较版本号。update-manifest.json的实际结构印证了这套设计顶层是schemaVersion: 1加一个products注册表其中java节点为status: legacy且只保留指向version_summary.json的updateFeedUrl供旧协议兼容next-electron为status: active并维护完整的releases数组当前含 1.0.0 起 27 个稳定版本每条带prerelease标志、releaseUrl与按平台/架构/包型组织的assets每个资产带sha512与sizenext-tauri节点已有两个 rc 预发布版本0.1.0-rc.1、0.1.0-rc.2next-macos-native节点状态为 planned。客户端侧的隔离逻辑可以在 updateService.ts 中逐行验证parseManifest会拒绝未注册、非 active 或版本重复的产品节点版本筛选逻辑为allowPrerelease 当前版本含 prerelease 段 ? 允许 : 只接受稳定版再在合格版本中取 SemVer 最大者与当前版本比较后才提示更新——这正是文档所述客户端自动隔离稳定与预发布更新的实现。Electron 的清单格式、资产选择和自动下载细节见 next/doc/update-products-and-assets.md该文档开头也明确声明仓库级版本号、Git tag、Release、Latest和 CI 隔离规则以本约定文档为准它只补充客户端更新清单与安装包选择的实现细节。8. 发布顺序正式发布按以下顺序执行文档第 8 节更新目标产品的版本来源、变更说明和必要文档并完成测试创建符合命名规则的 tagCI 校验版本一致性构建安装包和自动更新元数据由流水线核对平台、架构、签名状态、文件名和更新元数据所有目标校验通过后发布 Release并按产品角色设置 pre-release 和LatestRelease 资产可访问后再更新并启用该产品的更新清单验证 README 下载入口、客户端更新检查和安装流程。顺序中有一条安全红线不要在 Release 资产尚未可用时提前向已发布客户端暴露新版本以免客户端发现版本后无法下载。这对更新清单类产品尤其重要——update-manifest.json中一旦出现某版本的releases条目所有该产品的客户端在下次检查时就会认为存在新版本如果对应的 Release 资产不可用更新流程将直接指向 404。关于签名文档明确当前 Electron 产品线允许未签名发布流水线必须标注这一状态但不得因缺少证书而阻止 Release。这与 CI 实现一致——next-build-installers.yml中有一个Report unsigned release mode步骤推送 tag 触发时输出 warningThis workflow intentionally publishes unsigned Electron packages. macOS updates download a verified DMG in the background, then require manual installation. 未签名 macOS 客户端可以在后台下载并校验 DMG完成后提示用户打开 DMG 并按常规方式拖入应用程序但不得调用应用内自动安装具体限制见 next/doc/update-products-and-assets.md 的未签名发布策略一节。9. Electron 首个正式版本两个1.0.0如何共存文档第 9 节对 Electron 产品的起始版本做了显式钉死应用版本1.0.0 Git tagnext-electron-v1.0.0 Release 标题MooTool Next Electron 1.0.0该版本不占用、不删除、不重建历史 Java tagv1.0.0也不表示 Java 版本升级为 2.0.0——两个1.0.0属于不同产品线可以在同一仓库中独立存在。这条规则回答了多产品 monorepo 最常见的疑问新产品的 1.0.0 和老产品的 1.0.0 会不会冲突不会因为二者的 tagnext-electron-v1.0.0vsv1.0.0、Release 标题、安装包文件名、应用 ID 和更新清单节点全部不同update-manifest.json中next-electron的 releases 数组也确实以1.0.0为第一个稳定版本起步。10. 小结约定文档 清单文件 CI 脚本的三层闭环回顾整份 RELEASE_CONVENTIONS.md它的可执行性来自三层机制的互相咬合命名层tag 前缀 产品 ID产品 ID 更新清单节点键、应用 ID 前缀、安装包命名前缀一个标识贯穿所有发布面校验层scripts/manage_releases.py 把tag 与版本来源一致三语 notes 完整预发布不得抢 Latest等规则从文档约定升级为 CI 失败条件消费层客户端如 updateService.ts与清单文件update-manifest.json只认自己的产品节点Java 历史客户端继续走version_summary.jsondownload_links.json旧协议。对维护者而言日常只需记住三步改自己产品的版本来源文件、按前缀规则打 tag、让 CI 完成其余校验对扩展者而言接入新产品线的模板也很清晰——新增next-xxx-v*tag 前缀、专属工作流、update-manifest.json产品节点和独立应用 ID即可在不触碰其他产品的前提下加入这套多产品发布体系。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐GenOffice架构解析6个Electron应用如何共享一套引擎层Monorepo完整指南GenOffice架构解析6个Electron应用如何共享一套引擎层Monorepo完整指南 GenOffice 是一个免费开源的 AI 办公套件支持编人工智能AI 应用桌面应用AI AgentMCP 服务AI 技能shadPS4 0.7.0 一启动就崩这份 Windows 11 排障指南帮你 4 步救回 PS4 游戏shadPS4 0.7.0 一启动就崩这份 Windows 11 排障指南帮你 4 步救回 PS4 游戏 昨天例行升级我把 shadPS4 刷到了最新的 0虚拟化图形学终极指南如何使用Mise在同一台机器上管理多个Tuist版本终极指南如何使用Mise在同一台机器上管理多个Tuist版本 在iOS开发过程中不同项目可能需要不同版本的Tuist工具来确保兼容性和稳定性。Tuist作为开发工具CLI后端云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考