首页 / 资讯中心 / 文章详情

MooTool Next Flutter 发布与更新通道指南:多产品仓库中的版本、打包、CI 与客户端更新机制

MooTool Next Flutter 发布与更新通道指南:多产品仓库中的版本、打包、CI 与客户端更新机制 ★ FEATURED ARTICLE
桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载MooTool 采用“同一仓库、多个独立产品线”的发布方式本文聚焦其中基于 Flutter 的桌面产品线MooTool Next Flutter产品 IDnext-flutter系统讲解从版本来源、Git tag、安装包产物、本地打包与校验、CI 发布流水线到客户端更新检查与下载安装的完整链路。读完本文你将掌握在 monorepo 中为一条独立产品线发版的全过程并理解其“未签名发布 SHA-512 校验 手动安装”的更新协议设计。本文主体依据 next-flutter/docs/release.md 展开并结合作品线目录 next-flutter/ 中的脚本、Dart 源码、测试与 .github/workflows/next-flutter-build.yml 给出源码级佐证。一、发布身份产品 ID、版本来源与 Git tagMooTool Next Flutter 是一条与 Java、Electron、Tauri、macOS Native 平级的独立产品线其发布身份信息定义如下见 next-flutter/docs/release.md项目约定产品 IDnext-flutter版本来源next-flutter/pubspec.yaml中的version字段当前为0.1.01Git tagnext-flutter-v{semver}例如next-flutter-v0.1.0Release 标题MooTool Next Flutter {version}Latest标记make_latest: false不得占用全局 Latest在源码中这些身份常量集中定义于 next-flutter/lib/app/product.dartProduct.id next-flutter、displayName MooTool Next Flutter、applicationId com.rememberber.mootool.next.flutter、tagPrefix next-flutter-v。其中applicationId同时用于 macOS 的用户数据目录命名保证与 Java 等其他产品严格隔离。tag 前缀为什么必须有根据仓库根目录的总约定 RELEASE_CONVENTIONS.mdGit tag 在整个仓库内必须唯一。历史 Java 产品线已占用无前缀的v1.0.0v1.7.9命名空间因此新产品一律使用“产品 ID -v”前缀。next-flutter-v0.1.0与 Electron 的next-electron-v1.0.0、macOS Native 的next-macos-native-v*互不冲突同一仓库可以同时存在多个相同语义版本的 tag因为它们属于不同产品线。此外RELEASE_CONVENTIONS.md 还要求每个 tag 对应且仅对应一个产品版本的 ReleaseRelease 只上传当前产品的安装包和更新元数据Release Notes 只能比较同一产品线的前后两个 tag。二、安装包矩阵与命名规则next-flutter/docs/release.md规定的发布产物如下平台文件macOS arm64/x64MooTool-Next-Flutter-{version}-mac-{arch}.dmgWindows x64 安装版MooTool-Next-Flutter-{version}-win-x64-setup.exeWindows x64 便携版MooTool-Next-Flutter-{version}-win-x64-portable.zipLinux x64MooTool-Next-Flutter-{version}-linux-x64.AppImage、同前缀.deb这些文件名并非随手命名而是由更新模块中的PackageNames类统一生成并约束见 next-flutter/lib/core/update/package_names.dartmacOS 只允许dmg包型架构aarch64归一为arm64、amd64/x86_64归一为x64Windows 只接受nsis安装版与portable/zip便携版两种包型Linux 只接受appimage与deb两种包型。scripts/verify-package.py 用正则^MooTool-Next-Flutter-(版本)-(mac-(arm64|x64)\.dmg|win-x64-(setup\.exe|portable\.zip)|linux-x64\.(AppImage|deb))$对构建产物逐一对号入座同时计算 Base64 形式的 SHA-512 摘要并输出文件大小——这套“文件名 → 平台/架构/包型”的映射与更新客户端的选择逻辑完全同源避免发布端与客户端对资产描述出现分叉。全部未签名需用户手动确认所有安装包均未签名。macOS 上 Gatekeeper 会拦截用户需在 Finder 中右键选择“打开”Windows 可能触发 SmartScreen 提示。这是产品线的既定策略CI 中也以 warning 显式标注见后文并据此设计了客户端的“下载 → 校验 → 手动安装”更新协议而不是应用内自动静默安装。三、本地构建与发布前校验1. 打包入口在仓库根目录下的 next-flutter/scripts/package.sh 是对外的统一打包入口它按参数分派到平台专属脚本cd next-flutter ./scripts/package.sh macos # 需要完整 Xcode ./scripts/package.sh windows # 在 Windows 上 ./scripts/package.sh linux # 在 Linux 上package.sh内部逻辑非常克制只接受macos|windows|linux三个参数其余参数直接打印 usage 并退出且明确“Packages are unsigned. Missing platform toolchains fail instead of faking an installer.”——即必须在本机具备对应平台工具链缺工具链时报错退出而不是伪造一个空壳安装包。脚本分派到的build-macos.sh、build-windows.sh、build-linux.sh在 scripts 目录内与package.sh同级后三者通过exec调起产物统一输出到next-flutter/dist/。2. 版本与发布说明一致性校验python3 scripts/check-release.py --root . --tag next-flutter-v0.1.0scripts/check-release.py 承担“发布身份三重校验”从 pubspec.yaml 的正则^version:\s*([0-9][^\s])解析版本号校验release-notes/{version}.md存在且首行标题同时包含产品名MooTool Next Flutter与版本号对应 next-flutter/release-notes/0.1.0.md 的 H1 写法若传入--tag校验其严格等于next-flutter-v{version}。这个脚本同样被 CI 的checkjob 使用普通提交用check-release.py --root .tag 提交追加--tag ${{ github.ref_name }}从而在发布流水线入口就杜绝 tag 与版本来源漂移。3. 质量检查与本地运行配套的开发/检查脚本还包括scripts/check.shflutter pub getdart format --set-exit-if-changedflutter analyzeflutter test test/unit是提交前与 CIcheckjob 等价的质量门槛scripts/run.shflutter run -d macos支持传入--data-dir指定独立数据目录通过--dart-defineFLUTTER_APP_DATA注入方便在隔离环境做升级测试。四、CI 发布流水线tag 触发、三平台构建、非 Latest 发布产品线 CI 定义在 .github/workflows/next-flutter-build.yml与RELEASE_CONVENTIONS.md的“发布工作流必须通过 tag 前缀触发而不是根据整个仓库的最高版本判断产品”原则一致触发条件push 到next-flutter/**路径或.github/workflows/next-flutter-build.yml自身以及 tagnext-flutter-v*PR 路径过滤相同另支持workflow_dispatch手动触发打包。check jobubuntu-latest安装 stable Flutter依次执行check-release.py含 tag 一致性校验、flutter pub get、dart format检查、flutter analyze、flutter test test/unit。tag 提交还会输出一条醒目的 warningnext-flutter packages are intentionally unsigned...。package-macos / package-windows / package-linux分别在三平台 runner 上构建 DMG、setup.exe portable.zip、deb AppImage。macOS 构建显式设置CSC_IDENTITY_AUTO_DISCOVERY: false与CODE_SIGNING_ALLOWED: NO来确保产出未签名包Linux 额外安装clang cmake ninja-build pkg-config libgtk-3-dev liblzma-dev等 Flutter 桌面构建依赖。产物以next-flutter-{平台}为名上传 artifact。release job下载三个 artifact从pubspec.yaml动态读取版本号以next-flutter/release-notes/{version}.md为 Release Notes执行gh release create ${{ github.ref_name }} --latestfalse标题为MooTool Next Flutter ${version}。关键约束再次出现在 release job 末尾的 warning 中CI 不会更新根目录 update-manifest.json——“Enable the next-flutter node only after assets are reachable. make_latest is false.”也就是说即使 Release 已发布客户端更新清单也要等到安装包确实可下载后才启用详见下节。五、客户端更新通道只读next-flutter节点下载校验后手动安装1. 更新检查的数据流客户端更新逻辑位于 next-flutter/lib/core/update/ 与 next-flutter/lib/app/app_controller.dart完整链路为启动触发app_controller.dart 在应用启动且设置项autoCheckUpdates为 true 时静默调用checkForUpdates(quiet: true)。HTTP 拉取清单update_models.dart 中defaultUpdateFeedUrl指向仓库根 update-manifest.json当前托管在 master 分支并要求必须 HTTPS。解析与隔离update_service.dart 首先校验identity.productId Product.id防止更新服务被编译进错误的产品线再检查响应体非空且不超过 2 MB随后以schemaVersion 1、products为映射的前提解析清单只取products[next-flutter]节点且要求其status active否则视为未发布unpublished。版本比较使用 semver.dart 的语义化版本解析与比较稳定版客户端会自动忽略prerelease版本只有当前版本自身带预发布标识如-beta.1时才允许接收后续预发布。资产选择update_service.dart 的selectUpdateAsset按客户端平台darwin/win32/linux、架构arm64/x64支持universal回退与包型偏好macOS 仅dmgWindows 优先nsis后portableLinux 优先appimage后deb挑选下载项同时支持priority字段参与排序。2. 下载、SHA-512 校验与手动安装update_downloader.dart 对下载做三重防护HTTPS 强制URL scheme 非https直接抛错大小校验下载字节数与清单size必须一致SHA-512 校验对下载内容计算 SHA-512Base64 结果必须等于清单中sha512字段格式由正则^[A-Za-z0-9/]{86}$校验。校验通过后先写入带.download后缀与 pid 的临时文件再重命名到最终路径cache/updates/{fileName}避免半截文件被误用。之后客户端调用openLocalPath打开安装包macOS 用open、Windows 用cmd /c start、Linux 用xdg-open只负责唤起系统安装流程绝不宣称自动安装成功。对应到 app_controller.dart 的状态机idle → available → downloading → ready下载完成提示语为“updateReadyUnsigned”并支持用户取消下载cancelUpdateDownload。3. 没有匹配资产时只打开发布页当清单中不存在next-flutter节点、节点未激活或当前平台/架构没有匹配资产时UpdateCheckResult落入unpublished或“无资产”状态客户端不做下载而是直接打开defaultReleaseUrl产品 Releases 页面由用户从页面手动选择安装包。这正是 0.1.0 阶段的实际行为——next-flutter/release-notes/0.1.0.md 明确记载“资产可访问前不写更新清单节点”因此根目录 update-manifest.json 当前仅含java与next-electron两个产品节点next-flutter节点待首个 Release 资产就绪后再启用。4. 设置项更新行为由 next-flutter/lib/app/settings.dart 中的autoCheckUpdates默认false与autoDownloadUpdates默认false控制前者决定启动时是否静默检查后者决定发现可用更新后是否立即自动下载安装包注意自动下载不等于自动安装最终仍由用户手动打开安装包。六、用户数据隔离与卸载清理作为“可与其他产品同时安装”的独立产品线Next Flutter 的数据目录与其他实现严格错开见 next-flutter/lib/app/app_paths.dart 的defaultDataRoot()平台数据根目录macOS~/Library/Application Support/com.rememberber.mootool.next.flutterWindows%APPDATA%\MooToolNextFlutterLinux$XDG_DATA_HOME/mootool-next-flutter未设置时为~/.local/share/mootool-next-flutterapp_paths.dart中的verifyIsolation()会在启动时校验数据根路径禁止其复用MooToolNextElectron、mootool-next-electron、MooToolNextTauri、.MooTool、MooTool等其他产品的目录也不允许读取到productId不等于next-flutter的product.json——这是更新通道隔离之外的又一层数据隔离防线。next-flutter/docs/release.md对卸载给出了明确纪律Windows 卸载项名称独立不会与其他产品混淆删除用户数据需由用户自行清理上述三个平台的数据目录发布/清理脚本不得遍历删除MooTool*通配目录防止误伤同仓库其他产品的数据。七、多产品发布约定中的定位总结把 next-flutter/docs/release.md 放回 RELEASE_CONVENTIONS.md 的总框架中Next Flutter 的发布纪律可归纳为四条tag 隔离一律使用next-flutter-v*不碰 Java 的v*命名空间不与其他产品共用 tagLatest 隔离make_latest: false全局Latest只留给当前主力产品Electron测试版本必须标记 pre-releaseCI 隔离以 tag 前缀next-flutter-v*触发专属工作流只构建、校验、收集next-flutter/目录的产物从 tag 解析产品 ID 与版本号并校验与pubspec.yaml一致更新通道隔离客户端只读取update-manifest.json中products[next-flutter]节点不读取、不写入其他产品节点也不以仓库级/releases/latest判断更新。这套机制保证了 MooTool Next Flutter 与 Java、Electron、Tauri、macOS Native 可以互不干扰地同仓演进、独立发版、同时安装而 next-flutter/docs/release.md 正是这条产品线发布与更新协议的“一句话权威入口”——版本号、包名、构建命令、CI 触发规则、更新行为与卸载边界都在这一页以内。赞分享桌面应用开发工具【免费下载链接】MooToolHandy tool set for developers项目地址https://gitcode.com/gh_mirrors/mo/MooTool点击查看免费下载相关推荐MooTool Next Flutter 桌面版开发指南环境搭建、数据隔离、打包与更新通道MooTool Next Flutter 桌面版开发指南环境搭建、数据隔离、打包与更新通道 MooTool Next Flutter 是 MooTool 开源桌面应用开发工具MooTool Next Flutter P7 产品化验收只读更新通道、SHA-512 校验与未签名安装包工程化MooTool Next Flutter P7 产品化验收只读更新通道、SHA 512 校验与未签名安装包工程化 本文以 MooTool 仓库内 P7 验收报桌面应用开发工具MooTool Next Flutter 0.1.0 P7 构建环境解析Xcode 约束、未签名打包与只读更新通道MooTool Next Flutter 0.1.0 P7 构建环境解析Xcode 约束、未签名打包与只读更新通道 本文依据 MooTool 仓库中 P7 环桌面应用开发工具上一篇eslint-config-next 16 实战指南为 Next.js 项目配置 ESLint 9 Flat Config下一篇WezTerm Lua API 深度指南MuxTab 标签页对象完全解析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站