尧图网站建设 
Ente Auth 发布流程指南从版本号提升到 GitHub Release 与 Play Store 内部轨道【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente导读本文面向需要在 ente 单体仓库monorepo中为 Ente Authente 的两步验证/2FA 应用执行版本发布的开发者完整梳理了官方文档 mobile/apps/auth/docs/release.md 定义的发布链路从修改pubspec.yaml版本号、更新 Flathub 元数据到按 semver 规范打auth-前缀的 Git tag再由 GitHub Actions 自动产出草稿 Release含 Android APK 与各类桌面包并推送到 Play Store 内部轨道。读完本文你将掌握该仓库的实际发布操作步骤、tag 命名约定、release notes 的生成与过滤技巧并能结合仓库中的工作流与脚本理解每个步骤背后的自动化实现。发布前置准备版本号与元数据Ente Auth 是 Flutter 应用版本号的唯一事实来源是 mobile/apps/auth/pubspec.yaml 中的version字段。以当前仓库为例该文件第三行写着version: 4.4.261007发布的第一步是创建一个 Pull RequestPR将pubspec.yaml中的版本号提升到目标版本。注意这里使用的是 Flutter 标准的x.y.zbuild双段格式其中x.y.z是面向用户的语义化版本号之后的是构建号build number用于区分同一版本号的多次构建Play Store 依赖它来区分上传包。从 .github/scripts/flutter-version.mjs 的实现可以看到脚本通过正则^version:\s*(\d\.\d\.\d)\(\d)$解析该字段并提供了set、set-build、bump-build等命令来维护它。因此 PR 只需把version行改为目标值即可无需手工改动其它文件。大版本更新时补充 Flathub 元数据当本次发布属于 minor 或 major 版本提升时还需要为 Linux 桌面包Flathub 分发补充一条release记录。对应文件为 mobile/apps/auth/linux/packaging/enteauth.appdata.xml其releases段落结构如下releases release version4.4 date2026-03-30 / /releases每条release需要包含新版本的版本号version属性和发布日期date属性。这是 Flathub 应用商店元数据规范AppData的要求用于在 Linux 桌面商店页面展示版本历史。该文件同时还声明了应用的 IDenteauth、许可证AGPL-3.0、描述与截图等元数据发布时保持版本信息同步可以避免 Flathub 的元数据校验失败。Tag 命名约定semver auth-前缀版本号合并到main之后就可以为这次发布打 tag 了。官方约定如下使用 semver 语义化版本tag 统一以auth-作为前缀若同一即将发布的版本需要多个 beta 版本可以在 tag 末尾附加构建元数据build metadata例如auth-v1.2.3-beta3。之所以要在 tag 上加auth-前缀是因为 ente 是单体仓库Photos、Auth、Locker、Ensu 等多个应用共享同一个 Git 仓库与 tag 命名空间。前缀用于区分不同应用的版本避免v1.2.3这种通用 tag 产生歧义。类似地从 .github/docs/app-release.md 可以看到Ensu 使用的则是ensu-v0.1.16这类前缀规则完全一致。打 tag 并推送的命令如下以 v1.2.3 为例git tag auth-v1.2.3 git push origin auth-v1.2.3推送后GitHub 的 tag 推送事件会触发对应的构建工作流自动接管后续的发布产物生成。推送 tag 后自动触发的工作流从仓库的 .github/workflows/app-release.yml 可以看出各应用photos、auth、locker、ensu、photos-desktop共用同一条发布工作流通过workflow_dispatch的app输入参数区分。推送auth-vX.Y.Z形式的 tag 后工作流会自动完成两件核心事情创建草稿态 GitHub Release并挂载全部构建产物包括移动端 Android APK以及 LinuxAppImage/deb/pacman/rpm、macOS、Windows 等各平台桌面安装包在 Play Store 的内部轨道internal track创建一次新发布供内部测试与后续提升promote使用。从工作流的releasejob 与sync-docsjob 还可以看到更完整的自动化链路actionpromote阶段会校验 RC tag 指向的 commit 与 release 分支一致然后把auth-vX.Y.Z-rc草稿发布重命名为正式 tagauth-vX.Y.Z发布、删除 RC tag并在 docs 目录中打开一个更新 changelog 的 PR由 .github/scripts/sync-help-changelog.mjs 驱动。也就是说一次发布不仅是产物产出还包含版本状态清理与文档同步。版本与构建号如何被脚本维护发布工作流中的版本变更并非手工完成而是通过 .github/scripts/app-version.mjs 统一调度的。该脚本将各应用的版本操作转发到对应的版本脚本例如 Auth 走的是 .github/scripts/flutter-version.mjs并提供两个封装命令set-build-and-commit version build设置版本号与构建号后自动提交bump-build-and-commit将构建号加一后自动提交适用于需要重新出 RC 的场合。工作流start阶段会用set-build-and-commit把 release 分支的版本号设为正式版本并基于 CI 运行次数计算递增的构建号随后另开一个分支把main推进到下一个开发版本并创建 PR实现「发布一个版本、同时开启下一个版本」的循环。生成并整理 Release Notes工作流完成后需要到 GitHub 仓库的 Releases 页面找到自动创建的草稿 Release进行人工收尾保持 Release 标题与 tag 一致即标题应写为auth-v1.2.3避免与 tag 不一致导致管理混乱设置 Previous tag将其指向 auth 的上一个正式发布 tag例如auth-v1.1.9点击 Generate release notes让 GitHub 自动生成包含 PR 列表与新贡献者名单的 release notes。这里有一个关键细节需要注意由于 ente 是单体仓库生成的 release notes 会汇总 monorepo 中所有应用的全部 PR 与新贡献者范围远超本次 auth 发布。因此必须人工过滤只保留与 Ente Auth 相关的内容再将其作为最终的面向用户的 changelog 发布出去。为了让过滤工作更省力仓库还维护了变更片段change fragment机制每个面向用户的改动在 mobile/apps/auth/changes 目录下对应一个arbitrary-slug.md文件内容是一行简要描述见 mobile/apps/auth/changes/README.md。这些片段按字母序拼接后可作为 release notes 的素材来源也是工作流中「清除已发布片段并开启下一版本」时被删除的对象。与其它应用共用发布流程的注意事项Ente Auth 的发布流程并非孤例。根据 .github/docs/app-release.mdPhotos、Auth、Locker、Ensu、Photos Desktop 五个应用共用同一套流程只是把文档中的示例应用名如 ensu机械替换成目标应用名即可。对 Auth 而言几个具体差异点值得留意tag 前缀为auth-其它应用分别为photos-、locker-、ensu-等版本文件是 mobile/apps/auth/pubspec.yaml构建号格式为NNNNFlathub 元数据在 mobile/apps/auth/linux/packaging/enteauth.appdata.xml变更片段目录是 mobile/apps/auth/changes。另外从工作流实现看AuthPhotos、Locker 同理的发布还涉及 Play Store 内部轨道的上传与 TestFlightiOS分发每次推送 tag 触发构建后这些渠道会被自动更新这与桌面端草稿 Release 的生成是并行的两条产物通道。小结Ente Auth 的发布流程可以概括为五步闭环改版本号 PR →大版本时补 Flathub 元数据 → 打auth-前缀 tag 并推送 → 等待工作流产出草稿 Release 与 Play Store 内部轨道构建 → 在草稿 Release 上生成并过滤 release notes 后正式发布。整个过程的关键约定都沉淀在 mobile/apps/auth/docs/release.md 及 .github/docs/app-release.md 两份文档中而 .github/workflows/app-release.yml、.github/scripts/app-version.mjs 与 .github/scripts/flutter-version.mjs 则为每一步提供了可复用的自动化实现可作为后续维护发布脚本时的直接参考。【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ente Auth 发布流程指南：从版本号提升到 GitHub Release 与 Play Store 内部轨道
Ente Auth 发布流程指南从版本号提升到 GitHub Release 与 Play Store 内部轨道【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente导读本文面向需要在 ente 单体仓库monorepo中为 Ente Authente 的两步验证/2FA 应用执行版本发布的开发者完整梳理了官方文档 mobile/apps/auth/docs/release.md 定义的发布链路从修改pubspec.yaml版本号、更新 Flathub 元数据到按 semver 规范打auth-前缀的 Git tag再由 GitHub Actions 自动产出草稿 Release含 Android APK 与各类桌面包并推送到 Play Store 内部轨道。读完本文你将掌握该仓库的实际发布操作步骤、tag 命名约定、release notes 的生成与过滤技巧并能结合仓库中的工作流与脚本理解每个步骤背后的自动化实现。发布前置准备版本号与元数据Ente Auth 是 Flutter 应用版本号的唯一事实来源是 mobile/apps/auth/pubspec.yaml 中的version字段。以当前仓库为例该文件第三行写着version: 4.4.261007发布的第一步是创建一个 Pull RequestPR将pubspec.yaml中的版本号提升到目标版本。注意这里使用的是 Flutter 标准的x.y.zbuild双段格式其中x.y.z是面向用户的语义化版本号之后的是构建号build number用于区分同一版本号的多次构建Play Store 依赖它来区分上传包。从 .github/scripts/flutter-version.mjs 的实现可以看到脚本通过正则^version:\s*(\d\.\d\.\d)\(\d)$解析该字段并提供了set、set-build、bump-build等命令来维护它。因此 PR 只需把version行改为目标值即可无需手工改动其它文件。大版本更新时补充 Flathub 元数据当本次发布属于 minor 或 major 版本提升时还需要为 Linux 桌面包Flathub 分发补充一条release记录。对应文件为 mobile/apps/auth/linux/packaging/enteauth.appdata.xml其releases段落结构如下releases release version4.4 date2026-03-30 / /releases每条release需要包含新版本的版本号version属性和发布日期date属性。这是 Flathub 应用商店元数据规范AppData的要求用于在 Linux 桌面商店页面展示版本历史。该文件同时还声明了应用的 IDenteauth、许可证AGPL-3.0、描述与截图等元数据发布时保持版本信息同步可以避免 Flathub 的元数据校验失败。Tag 命名约定semver auth-前缀版本号合并到main之后就可以为这次发布打 tag 了。官方约定如下使用 semver 语义化版本tag 统一以auth-作为前缀若同一即将发布的版本需要多个 beta 版本可以在 tag 末尾附加构建元数据build metadata例如auth-v1.2.3-beta3。之所以要在 tag 上加auth-前缀是因为 ente 是单体仓库Photos、Auth、Locker、Ensu 等多个应用共享同一个 Git 仓库与 tag 命名空间。前缀用于区分不同应用的版本避免v1.2.3这种通用 tag 产生歧义。类似地从 .github/docs/app-release.md 可以看到Ensu 使用的则是ensu-v0.1.16这类前缀规则完全一致。打 tag 并推送的命令如下以 v1.2.3 为例git tag auth-v1.2.3 git push origin auth-v1.2.3推送后GitHub 的 tag 推送事件会触发对应的构建工作流自动接管后续的发布产物生成。推送 tag 后自动触发的工作流从仓库的 .github/workflows/app-release.yml 可以看出各应用photos、auth、locker、ensu、photos-desktop共用同一条发布工作流通过workflow_dispatch的app输入参数区分。推送auth-vX.Y.Z形式的 tag 后工作流会自动完成两件核心事情创建草稿态 GitHub Release并挂载全部构建产物包括移动端 Android APK以及 LinuxAppImage/deb/pacman/rpm、macOS、Windows 等各平台桌面安装包在 Play Store 的内部轨道internal track创建一次新发布供内部测试与后续提升promote使用。从工作流的releasejob 与sync-docsjob 还可以看到更完整的自动化链路actionpromote阶段会校验 RC tag 指向的 commit 与 release 分支一致然后把auth-vX.Y.Z-rc草稿发布重命名为正式 tagauth-vX.Y.Z发布、删除 RC tag并在 docs 目录中打开一个更新 changelog 的 PR由 .github/scripts/sync-help-changelog.mjs 驱动。也就是说一次发布不仅是产物产出还包含版本状态清理与文档同步。版本与构建号如何被脚本维护发布工作流中的版本变更并非手工完成而是通过 .github/scripts/app-version.mjs 统一调度的。该脚本将各应用的版本操作转发到对应的版本脚本例如 Auth 走的是 .github/scripts/flutter-version.mjs并提供两个封装命令set-build-and-commit version build设置版本号与构建号后自动提交bump-build-and-commit将构建号加一后自动提交适用于需要重新出 RC 的场合。工作流start阶段会用set-build-and-commit把 release 分支的版本号设为正式版本并基于 CI 运行次数计算递增的构建号随后另开一个分支把main推进到下一个开发版本并创建 PR实现「发布一个版本、同时开启下一个版本」的循环。生成并整理 Release Notes工作流完成后需要到 GitHub 仓库的 Releases 页面找到自动创建的草稿 Release进行人工收尾保持 Release 标题与 tag 一致即标题应写为auth-v1.2.3避免与 tag 不一致导致管理混乱设置 Previous tag将其指向 auth 的上一个正式发布 tag例如auth-v1.1.9点击 Generate release notes让 GitHub 自动生成包含 PR 列表与新贡献者名单的 release notes。这里有一个关键细节需要注意由于 ente 是单体仓库生成的 release notes 会汇总 monorepo 中所有应用的全部 PR 与新贡献者范围远超本次 auth 发布。因此必须人工过滤只保留与 Ente Auth 相关的内容再将其作为最终的面向用户的 changelog 发布出去。为了让过滤工作更省力仓库还维护了变更片段change fragment机制每个面向用户的改动在 mobile/apps/auth/changes 目录下对应一个arbitrary-slug.md文件内容是一行简要描述见 mobile/apps/auth/changes/README.md。这些片段按字母序拼接后可作为 release notes 的素材来源也是工作流中「清除已发布片段并开启下一版本」时被删除的对象。与其它应用共用发布流程的注意事项Ente Auth 的发布流程并非孤例。根据 .github/docs/app-release.mdPhotos、Auth、Locker、Ensu、Photos Desktop 五个应用共用同一套流程只是把文档中的示例应用名如 ensu机械替换成目标应用名即可。对 Auth 而言几个具体差异点值得留意tag 前缀为auth-其它应用分别为photos-、locker-、ensu-等版本文件是 mobile/apps/auth/pubspec.yaml构建号格式为NNNNFlathub 元数据在 mobile/apps/auth/linux/packaging/enteauth.appdata.xml变更片段目录是 mobile/apps/auth/changes。另外从工作流实现看AuthPhotos、Locker 同理的发布还涉及 Play Store 内部轨道的上传与 TestFlightiOS分发每次推送 tag 触发构建后这些渠道会被自动更新这与桌面端草稿 Release 的生成是并行的两条产物通道。小结Ente Auth 的发布流程可以概括为五步闭环改版本号 PR →大版本时补 Flathub 元数据 → 打auth-前缀 tag 并推送 → 等待工作流产出草稿 Release 与 Play Store 内部轨道构建 → 在草稿 Release 上生成并过滤 release notes 后正式发布。整个过程的关键约定都沉淀在 mobile/apps/auth/docs/release.md 及 .github/docs/app-release.md 两份文档中而 .github/workflows/app-release.yml、.github/scripts/app-version.mjs 与 .github/scripts/flutter-version.mjs 则为每一步提供了可复用的自动化实现可作为后续维护发布脚本时的直接参考。【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考