AutoClip 周更发版清单实战：从合并 PR 到 Release 出包的全自动流水线

音视频AI 应用后端前端【免费下载链接】autoclipAutoClip : AI-powered video clipping and highlight generation · 一款智能高光提取与剪辑的二创工具项目地址https://gitcode.com/GitHub_Trending/autoc/autoclip点击查看免费下载本文以 AutoClip 仓库根目录下的 RELEASE_CHECKLIST.md 为核心骨架结合scripts/发版工具、.github/workflows/desktop-build.yml构建流水线及CHANGELOG.md实际格式完整还原这套「每周一版、25 分钟自动出包」的发版方法论。读完你可以直接照搬这套流程掌握bump_version.py的四处版本号统一机制、release_notes.py的 Release 正文自动生成原理、tag 触发双平台打包的 CI 编排以及哪些环节必须由人亲自验证。一、发版哲学每周一版版本号只是周次编号AutoClip 的发版节奏写在 RELEASE_CHECKLIST.md 开头核心信条可以概括为三句话节奏固定每周一版版本号1.3.0 → 1.4.0 → …递增周中热修用x.y.1如1.2.1。目标不是这版把什么做完而是「把 main 上已验证的改动每周发出去」。HANDOFF.md里的 v1.3 / v1.4 分组只是优先级队列不是发版承诺。一次完整发版约 25 分钟从打 tag 到 Release 出包全部由desktop-build.yml自动完成人只需要按清单打勾。这套理念直接反映在版本号语义上主版本号1.3.0 → 1.4.0的递进不意味着功能大版本而是第几周的周次编号。比如仓库当前 CHANGELOG 显示1.3.0 - 2026-09-20、1.2.1 - 2026-09-06间隔恰好一周。二、周中周一至周五合 PR 的三条纪律清单对「平时」只有三条要求但每一条都有明确的可执行标准1. 只合并 CI 全绿 有验证记录的 PRPR 描述里必须写清楚「怎么验的」。外部 PR 按 HANDOFF.md 第三节的原则处理——AutoClip 对外部 PR 采取「谨慎对待能不合入就不合入采纳的改动以 cherry-pick 进自己的 PR 并保留原作者署名」的策略。2. 每个合入的 PR 都在 CHANGELOG 的[未发布]留一行写给用户看不写内部实现。这保证了 CHANGELOG.md 顶部的## [未发布]段落始终是下一版 Release 正文的原料。以当前仓库为例[未发布]段落在没有改动时会被bump_version.py自动填入_本周尚无改动_占位符。3. 每版至少带一条失败态改善或安装体验改善这是 issue 区「最缺的两类」改进。从 CHANGELOG 的1.3.0段落可以看到具体落地形态例如「失败要像失败」——LLM 未配置、字幕缺失、大纲提取失败、时间线为空、ffmpeg 零产出时流水线一律进入failed状态并携带阶段SUBTITLE / ANALYZE / EXPORT与可执行的提示文案杜绝「Completed · 0 切片」这类误导性状态。另外周报scripts/weekly_digest.py里新出现的高频问题当周能修就进这版修不了写进HANDOFF.md待办。这个脚本合并 GitHub 新 issue、飞书表单新条目与 PostHog 反馈事件输出 markdown 周报是「问题驱动发版」的数据来源。三、切版周六/周日冻结后 24 小时内四道关卡切版是流程的核心冻结后 24 小时内按顺序完成以下动作关卡 1确认 main CI 绿gh run list --branch main --limit 1仓库的 CI 由 .github/workflows/ci.yml 承担backend / frontend / docker-smoke 三个维度main 分支最新一次 run 必须全绿才允许进入下一步。关卡 2本地跑全量验证清单明确要求跑三件套python -m pytest backend/tests cd frontend npm run lint npm run typecheck npm run build python -m backend.eval其中pytest backend/tests覆盖仓库 20 个测试文件如test_pipeline_failures.py、test_cli.py、test_settings_web_mode.py等python -m backend.eval是出片质量回归入口用 backend/eval/cases/ 下的合成用例约束 step1–step5 的提示词与评分行为不退化。关卡 3通读 CHANGELOG[未发布]段落三个检查点措辞面向用户、每条能对应到 issue 或 PR、没有泄露内部路径/密钥。这一步是防「发版翻车」的人肉闸门——Release 正文直接由这段生成写不好就发布到所有用户面前。关卡 4统一版本号 滚动 CHANGELOGpython scripts/bump_version.py X.Y.0 --commit git push origin main git tag vX.Y.0 git push origin vX.Y.0第一条命令完成「改四处版本号 把[未发布]滚成[X.Y.0] - 日期」第二条命令推 tag 触发构建流水线。注意tag 由人打脚本不代打。四、bump_version.py 深入四处版本号如何保持同步scripts/bump_version.py 是整个发版流程的版本号唯一事实源工具它保证以下四处版本号永远一致文件修改位置src-tauri/tauri.conf.jsonJSON 顶层version字段src-tauri/Cargo.toml[package]段的version ...pyproject.toml[project]段的version ...backend/core/desktop_config.pyos.getenv(AUTOCLIP_APP_VERSION, ...)的回退值脚本的三种用法python scripts/bump_version.py 1.3.0 # 改文件、滚 CHANGELOG不提交 python scripts/bump_version.py 1.3.0 --commit # 顺带 git commit不打 tagtag 由人打 python scripts/bump_version.py --check # 只检查各处版本号是否一致CI 可用从源码实现看有四个值得注意的细节正则在 Cargo.toml / pyproject.toml 中只替换指定 section 段内的version _sub_section函数用[^\[]*?限定范围避免误伤依赖表里的版本号找不到目标段会直接SystemExit报错。--check模式打印四处版本号并对比不一致时返回退出码 1可直接接入 CI 作为版本一致性闸门。CHANGELOG 滚动roll_changelog把## [未发布]原地替换为## [未发布]\n\n_本周尚无改动_\n\n## [X.Y.Z] - 日期并同步更新文件底部的 compare 链接Unreleased指向新 tag 的compare/v{new}...HEAD同时补一条compare/v{prev}...v{new}的版本对比链接。若 CHANGELOG 已存在该版本段则跳过不会重复滚动。--commit模式只git add那五个文件四个版本文件 CHANGELOG并提交chore: release vX.Y.Z打印下一步提示git tag v{new} git push origin main v{new}。值得一提该脚本明确只用标准库没有任何第三方依赖任何环境都能直接跑。五、打 tag 触发 desktop-build.yml25 分钟出包的流水线推送v*tag 后.github/workflows/desktop-build.yml 被触发这是整个自动化的核心。其编排结构如下触发方式两种push tagsv*正式发版构建 挂 Release。workflow_dispatch手动触发可以只勾选 macOS 或只勾选 Windows 做试构建清单里少一个 对应平台构建失败的排查手段。两个并行构建 jobbuild-macos-arm64macos-14runnerApple Silicon跑scripts/build_macos_arm.sh产物为AutoClip.Desktop_{ver}_aarch64.dmg。build-windows-x64windows-latestrunner在Git Bash下跑scripts/build_windows_x64.shworkflow 里显式设置git config --global core.autocrlf false强制 LF 行尾防止 CRLF 导致 shell 脚本$\r: command not found产物为 NSIS 安装包AutoClip.Desktop_{ver}_x64-setup.exe。两个 job 都走PBSpython-build-standalone路线便携 Python 后端源码 静态 ffmpeg/ffprobe 打进安装包用户无需预装 Python 和 ffmpeg。macOS 构建完把python/ backend/ ffmpeg/注入.app再做 ad-hoc 签名Windows 因安装包无法事后注入资源在src-tauri/tauri.windows.conf.json的bundle.resources中声明由 Tauri 打进 NSIS——这是两个平台唯一的结构差异详见 scripts/README.md。release job汇总 生成正文releasejob 的设计有两个亮点单 job 汇总而不是每个平台各自上传避免两个 job 竞争创建同一 tag 的 Releaseneeds: [build-macos-arm64, build-windows-x64]但if: startsWith(github.ref, refs/tags/v) !cancelled()——即使某个平台构建失败也不阻塞另一个平台的产物上传对应清单里少一个 对应平台构建失败看 run 日志的排查逻辑。release job 调用python3 scripts/release_notes.py ${{ github.ref_name }} -o release_body.md生成正文再用softprops/action-gh-releasev2创建/更新 Release 并挂载dist/*全部产物。workflow 顶部还声明了permissions: contents: write——没有这个权限声明默认只读的 GITHUB_TOKEN 会导致上传 403。六、release_notes.pyRelease 正文从 CHANGELOG 自动生成scripts/release_notes.py 承担不手工写 Release 正文的承诺。它的机制是抽段落正则^## \[{version}\][^\n]*\n(.*?)(?^## \[|\Z)从 CHANGELOG.md 中抽出目标版本段落的正文不含标题行直到下一个## [为止。拼平台说明把该段落与内置的PLATFORM_NOTES模板拼接输出形如## AutoClip Desktop v1.3.0的完整正文。兜底CHANGELOG 里找不到该版本段时只输出平台说明 指向 CHANGELOG 的提示不让发版失败。本地预览用法python scripts/release_notes.py v1.3.0 # 打印到 stdout python scripts/release_notes.py v1.3.0 -o body.md # 写到文件生成的平台说明表格非常实战macOS 包注明「未公证右键应用 → 打开」Windows 包注明「未签名SmartScreen → 更多信息 → 仍要运行」并强调两个包都内置便携 Python 与静态 ffmpeg、Windows 安装包按用户安装不需要管理员权限、缺 WebView2 会自动下载——这些正是 RELEASE_CHECKLIST.md「发版后真机验证」环节要核对的用户体验点。七、发版后当天人做的部分CI 覆盖不到清单明确强调真机验证必须人做。CI 只能保证构建成功验证不了装到用户电脑上能不能用。Windows优先级最高干净机器装-setup.exe→ 能启动 → 设置页保存 provider → 跑通一条本地视频。清单特别标注「Windows 下载量是 DMG 的 3 倍这一步不能省」。这与 HANDOFF.md 中截至 2026-09-20 下载量 Windows 1136 / DMG 334的数据互相印证——Windows 已是 AutoClip 的主力平台最可能翻车点包括 NSIS 打包的几千个 Python 文件、WebView2 引导、%APPDATA%\AutoClip数据目录。macOS右键打开 DMG 里的应用 → 同样跑一遍完整流程ad-hoc 签名需右键 → 打开绕过 Gatekeeper。随后是三类收尾工作更新置顶帖 #96的版本号与「v1.x 修了什么」小节该帖是 issue 区用不了类问题的统一引导入口关闭已修复 issue上一版 Release 的needs-info/ 已修复 issue引导用户升级后关闭模板回复见 HANDOFF.md 第三节同步 HANDOFF.md头部「更新日期 · mainsha」与第四节勾选状态同步保证它始终是项目状态的单一事实来源。八、热修流程周中发现影响面大的 bug不等周末按一条最短路径处理单独分支 → PR → CI 绿 → 合入 → bump_version.py X.Y.1 --commit → 打 tag即版本号从X.Y.0升到X.Y.1周中热修用x.y.1的语义在此兑现不攒到周末。仓库历史上1.2.1就是典型热修版——HANDOFF.md 记录它是止血版让 README 推荐的 docker compose 路径和本地脚本路径真正能跑通一次完整处理一口气修掉了 7 条可复现问题.dockerignore 误排除、CRLF 行尾、硬编码路径、队列未消费、Redis 诊断硬编码 localhost 等。九、明确不做三条红线清单用「明确不做」小节划出边界防止流程被顺手破坏不在切版日合新功能周六冻结后只合修 CI / 修 CHANGELOG 措辞的改动不手工编辑四处版本号用脚本、不手工写 Release 正文从 CHANGELOG 生成不为了凑一版大的推迟发版main 上有可发的就发——这是每周一版理念的最后一道保障。十、相关文件速查用途位置版本号统一 CHANGELOG 滚动scripts/bump_version.pyRelease 正文生成被desktop-build.yml的 release job 调用scripts/release_notes.py构建 workflowtagv*触发workflow_dispatch可只勾一个平台试构建.github/workflows/desktop-build.yml打包脚本macOS / Windows共用平台无关步骤scripts/build_macos_arm.sh、scripts/build_windows_x64.sh、scripts/lib/desktop_build_common.sh构建与运维脚本说明scripts/README.md每周反馈周报scripts/weekly_digest.py当前状态 / 待办版本分组、外部 PR 原则、issue 治理HANDOFF.md面向用户的变更记录[未发布]段是 Release 正文原料CHANGELOG.md桌面后端注入的版本号回退值backend/core/desktop_config.py小结AutoClip 的周更流程本质上是把发版从一件需要人工记忆大量步骤的事压缩成一份 20 余项的勾选清单 两个标准库脚本 一条双平台 CI 流水线。它的可复制经验有三点版本号只由脚本改消灭手工漂移、Release 正文只从 CHANGELOG 生成消灭重复劳动、真机验证只由人做补上 CI 覆盖不到的最后一公里。对任何需要维护桌面端周更节奏的项目这套「周中合绿 PR 周末统一版本打 tag 自动出包挂 Release 当天真机验证」的组合拳都值得直接照搬。赞分享音视频AI 应用后端前端【免费下载链接】autoclipAutoClip : AI-powered video clipping and highlight generation · 一款智能高光提取与剪辑的二创工具项目地址https://gitcode.com/GitHub_Trending/autoc/autoclip点击查看免费下载相关推荐CloudNativePG 版本发布全流程实战指南release 分支管理、自动化流水线与发布产物清单CloudNativePG 版本发布全流程实战指南release 分支管理、自动化流水线与发布产物清单 CloudNativePG 是运行于 Kubernet云原生数据库高可用灾备容器编排OmniRoute 发布清单实战指南从版本号到上线的完整 Release 流程OmniRoute 发布清单实战指南从版本号到上线的完整 Release 流程 本指南系统讲解 OmniRoute 开源项目在打 tag、发布 npm 包与部后端API网关LLM 网关人工智能大模型MCP 服务桌面应用RxDB 版本发布流程详解从 pre-release 检查清单到自动化 Release 工作流RxDB 版本发布流程详解从 pre release 检查清单到自动化 Release 工作流 本文以仓库 orga/release checklist.md数据库NoSQL嵌入式数据库实时数据库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考