AI 应用大模型RAG语音后端前端桌面应用【免费下载链接】BiliNoteAI 视频笔记生成工具 让 AI 为你的视频做笔记项目地址https://gitcode.com/gh_mirrors/bi/BiliNote点击查看免费下载本篇是 BiliNote 开源仓库的发版执行手册Release Manager 视角完整覆盖从develop分支切出发布分支、编写 CHANGELOG、双 PR 合并与回灌、打 tag 触发 CI 自动构建插件产物到人工上传 Chrome Web Store / Edge Add-ons / Firefox AMO 以及桌面端Tauri发布的每一步。读完你不仅能按步复现一次完整发版还能理解release-extension.yml、commitlint 等仓库基础设施如何在底层约束和自动化这条发布链路。发版全景一条主线三类交付物BiliNote 采用简化 Git Flow详见 CONTRIBUTING.md发版主线固定在develop → release/X.Y.Z → master → tag这条路径上。RELEASING.md 给出的完整流程如下develop ──→ release/X.Y.Z ──→ PR ─→ master ──→ 打 tag vX.Y.Z │ │ │ └──→ PR 回灌 ──→ develop └──→ CI 自动构建插件产物 挂到 GitHub Release ↓ 人工上传商店Chrome/Edge/Firefox一次发版最终产出三类交付物浏览器插件由 push tag 触发的 CI 构建出.zip/.xpi/.crx并挂到对应 GitHub Release、桌面端安装包Tauri 构建同样由v*tag 触发以及人工提交商店审核Chrome / Edge / Firefox 三商店审核周期普遍 1-3 个工作日。第一步从 develop 切发布分支在本地终端执行git checkout develop git pull origin develop git checkout -b release/X.Y.Z版本号遵循SemVer 语义化版本规范MAJOR.MINOR.PATCH。与之对应的分支命名规范在 CONTRIBUTING.md 中有明确约定release/版本号必须与实际 tag 一致如release/2.1.0↔v2.1.0全小写、用中划线连接。仓库的简化 Git Flow 中release/*是短生命周期分支创建来源develop合并去向masterdevelop合并后删除它的定位是版本冻结、回归、发版准备——冻结期内不允许再合入新需求只允许修复发布缺陷。第二步写 CHANGELOG、更新版本号在release/X.Y.Z分支上完成三处文档更新编辑 CHANGELOG.md在文件头部新增## [X.Y.Z] - YYYY-MM-DD段。仓库明确采用 Keep a Changelog 分类体系Added / Changed / Fixed / Removed / Security / Internal。实际仓库中的写法可参考 CHANGELOG.md例如## [2.4.4] - 2026-06-23下挂### Security[2.4.3]下挂### Fixed每条变更都带 issue 编号与具体说明。编辑 README.md 顶部标题中的版本号并新增「vX.Y.Z 新增」摘要段与 CHANGELOG 中该版本新增内容对应仓库历史如### v2.3.0 新增段即是此类摘要。重大变更同步更新 CLAUDE.md仓库结构 各 workspace 开发命令说明涉及工作区级重大调整时更新。随后提交并推送git commit -am docs: vX.Y.Z CHANGELOG README 版本 git push -u origin release/X.Y.Z第三步合并 master 回灌 develop双 PR在 GitHub 上发起两个 PR两者合并方式都必须使用 Merge commit--no-ffPRbase合并方式合并后 commit 标题release/X.Y.Z→mastermasterMerge commit (--no-ff)chore(release): vX.Y.Zrelease/X.Y.Z→developdevelopMerge commit (--no-ff)chore(release): merge release/X.Y.Z back into develop为什么合并标题必须符合 commitlint⚠️ Merge commit 的标题必须符合type(scope): subject格式——仓库的 commitlint 会在 push 到master/develop时校验。历史上用过Release vX.Y.Z这种形式会被 commitlint 报type-empty/subject-empty。这一点有完整的仓库实现支撑根目录的 .commitlintrc.json 基于commitlint/config-conventional把type-enum白名单限定为feat / fix / docs / style / refactor / perf / test / build / ci / chore / ui / revert十二种.github/workflows/commitlint.yml 在develop/master的 push 以及所有 PR 上运行 commitlintfetch-depth: 0以便检查全部提交历史。这也是为什么发版 merge commit 标题统一写成chore(release): ...——chore是合法 type(release)是 scopevX.Y.Z是 subject。分支保护与回灌的意义master分支保护要求review 通过才能合并。回灌develop是为了把发版冻结期内的小修同步回开发主干避免修复丢失。CONTRIBUTING.md 中强调release/*合入master与回灌develop均使用 Merge commit保留发版结构而日常feature/*/fix/*合入develop推荐 Squash and merge 以保持历史线性。第四步打 tag触发 CI 自动构建git checkout master git pull origin master git tag -a vX.Y.Z -m BiliNote vX.Y.Z 主线 - ... 详见 CHANGELOG.md git push origin vX.Y.Zpush tag会自动触发 .github/workflows/release-extension.yml构建插件并把.zip/.xpi/.crx挂到对应 GitHub Release。CI 构建链路做了什么对照工作流源码触发与构建细节如下触发条件on.push.tags匹配v*即任何v开头的 tagrelease-extension.yml构建环境ubuntu-latestpnpm固定 9 系、Node 20cache-dependency-path指向BillNote_extension/pnpm-lock.yaml——这两个版本钉死与仓库历史中「pnpm 11 不兼容 Node 20」等构建事故的修复直接相关见 README.md 的 v2.2.1 / v2.2.2 修订记录构建命令pnpm install --frozen-lockfile→pnpm build对应 BillNote_extension/package.json 中的build脚本生产模式依次执行 clear / build:web / build:prepare / build:background / build:js产物打包pnpm pack:zipjszip 打包extension/为extension.zipChrome / Edge 上传格式、pnpm pack:xpiweb-ext 构建 Firefox 扩展、pnpm pack:crx自托管 sideload 用crx 的稳定性说明crx 需要稳定key.pem才能保持插件 ID 不变。CI 中没有该密钥时用continue-on-error: true跳过、不阻塞主流程若想生成稳定 crx需把 key 存入 secretEXTENSION_CRX_KEY并解开工作流中的注释release-extension.yml命名与挂载把extension.zip/.xpi/.crx重命名为bilinote-extension-${VERSION}.zip等带版本后缀的产物再由softprops/action-gh-releasev2挂到对应 Releasefail_on_unmatched_files: false缺某类产物不报错。桌面端同样由v*tag 触发.github/workflows/main.yml构建时从 tag 注入版本号到tauri.conf.jsongithub.ref_name去掉前缀v如v2.3.2→2.3.2确保产物版本与 Release 版本对齐——这一步对应 CHANGELOG 中「桌面端构建产物版本恒为 2.0.0」的修复CHANGELOG.md。第五步创建 GitHub Release如还没有CI 默认会创建 / 更新vX.Y.Z对应的 Release。如果你想自己撰写 release notes打开 GitHub 仓库的 Releases → New 页面Tag 选择vX.Y.ZTitle 填vX.Y.ZBody 直接粘贴 CHANGELOG.md 中对应版本的段落CI 跑完后Release 页面会自动出现bilinote-extension-X.Y.Z.zip/.xpi/.crx产物。第六步人工上传各商店商店审核普遍 1-3 个工作日。建议顺序先 Chrome → Edge → FirefoxEdge 接受与 Chrome 同一份 zip。Chrome Web Store进入 Chrome Web Store 开发者控制台选 BiliNote → 左侧Package→Upload new package上传bilinote-extension-X.Y.Z.zip检查 listing描述 / 图标 / 截图无变化可保持点Submit for review。Microsoft Edge Add-ons进入 Microsoft Partner Center 的 Edge 插件仪表盘选 BiliNote →New submission上传同一份.zipEdge Add-ons 与 Chrome 完全兼容 MV3提交审核。Firefox Add-ons (AMO)进入 addons.mozilla.org 的开发者后台选 BiliNote →Upload New Version上传bilinote-extension-X.Y.Z.xpi选择「在 AMO 公开」或「自托管」提交审核。桌面端 (Tauri)仓库已有 GitHub Actions 在v*tag 时构建桌面端安装包并自动挂到 GitHub Release无需额外操作。main.yml会收集.dmg/.msi/ NSIS.exe安装包并上传main.yml。第七步清理 release 分支# release 分支已合到 master 与 develop删掉 git push origin --delete release/X.Y.Z git branch -d release/X.Y.Z这符合 CONTRIBUTING.md 的合并规范短期分支合并完成后必须删除远端 本地已完成的分支不得继续承接新需求。可选配置 secrets 实现商店自动发布.github/workflows/release-extension.yml 末尾有三段商店自动发布的 job 注释publish-chrome/publish-edge/publish-firefox默认禁用。要启用在 GitHub 仓库 Settings → Secrets and variables → Actions 中添加对应 secrets商店需要的 secretChromeCHROME_EXTENSION_ID、CHROME_CLIENT_ID、CHROME_CLIENT_SECRET、CHROME_REFRESH_TOKENEdgeEDGE_PRODUCT_ID、EDGE_CLIENT_ID、EDGE_API_KEYFirefoxFIREFOX_ADDON_UUID、FIREFOX_API_KEY、FIREFOX_API_SECRET解开工作流文件末尾publish-chrome/publish-edge/publish-firefox三个 job 的注释之后 push tag 时即自动发布到商店。工作流注释中还给出了各商店 secret 的获取方式指引Chrome 参照 chrome-webstore-upload-cli 的 Google API key 生成说明需CHROME_CLIENT_ID/CHROME_CLIENT_SECRET/CHROME_REFRESH_TOKEN对应 OAuth 客户端与刷新令牌Edge 使用 Edge Add-ons APIEDGE_PRODUCT_ID即插件 product IDEDGE_CLIENT_ID/EDGE_API_KEY为 Azure 应用凭证Firefox 在 AMO 开发者后台的 API Key 页面生成。三个 job 分别基于mnao305/chrome-extension-upload、wdzeng/edge-addon、trmcnvn/firefox-addon三个 GitHub Action 实现产物路径均指向带版本号的bilinote-extension-${github.ref_name}.zip/.xpi。紧急 hotfix 发版不走 release/走 hotfix/线上紧急问题不经过release/*分支git checkout master git pull git checkout -b hotfix/scope-事项 # … 修复 ... # PR basemaster 合入同时 PR basedevelop 回灌合入master后通常打patch tag如v2.1.1CI 流程与常规发版相同。CONTRIBUTING.md 对 hotfix 的约束包括仅处理线上阻断性 / 高优先级缺陷非紧急问题不得绕过develop直接走热修若当前存在release/*即将发布需评估是否同步到对应 release 分支避免修复丢失。历史发布快查VersionDateTag2.1.02026-05-07v2.1.02.0.0(上游 web 端 v2.0.0)v2.0.0注表格中的 Tag 指向 GitHub Releases 页面可在仓库 Releases 板块查看对应版本的说明与产物。该表为发版手册中的历史记录最新版本信息以 CHANGELOG.md 顶部与 README.md 标题版本号为准。附发版涉及的仓库文件速查文件作用RELEASING.md本发版手册面向 Release ManagerCONTRIBUTING.md分支模型、提交规范、合并规范发版流程的上游约定CHANGELOG.mdKeep a Changelog 格式的版本变更记录.commitlintrc.jsoncommitlint 规则type 白名单等.github/workflows/commitlint.ymlpush 到 master/develop 与 PR 时的提交信息校验.github/workflows/release-extension.ymlv*tag 触发的插件构建 产物挂 Release含注释的商店自动发布 job.github/workflows/main.yml桌面端 Tauri 构建 版本号注入 安装包挂 ReleaseBillNote_extension/package.json插件build/pack:zip/pack:xpi/pack:crx打包脚本整套发版流程的本质是用「简化 Git Flow 的分支纪律 commitlint 的提交规范强制 tag 触发的工作流自动化」把一次发布固化为可重复、可审计、可回滚的标准动作文档与版本号先行双 PR 保证主干与开发线同步tag 一打插件与桌面端产物自动就绪剩下的只有三商店的人工审核环节。赞分享AI 应用大模型RAG语音后端前端桌面应用【免费下载链接】BiliNoteAI 视频笔记生成工具 让 AI 为你的视频做笔记项目地址https://gitcode.com/gh_mirrors/bi/BiliNote点击查看免费下载相关推荐终极指南ChatGPT Google Extension一键发布到Chrome与Firefox商店的完整流程终极指南ChatGPT Google Extension一键发布到Chrome与Firefox商店的完整流程 ChatGPT Google ExtensionWebChatGPT扩展终极上架指南Chrome、Firefox和Edge商店完整策略WebChatGPT扩展终极上架指南Chrome、Firefox和Edge商店完整策略 WebChatGPT是一款革命性的浏览器扩展它让ChatGPT拥有了NoneBot2插件发布指南从开发到商店上架全流程NoneBot2插件发布指南从开发到商店上架全流程 前言 NoneBot2作为一款优秀的Python异步机器人框架其插件生态是其强大功能的核心支撑。本文将详后端即时通讯上一篇Workflow开源审批系统5分钟构建企业级流程管理平台下一篇如何扩展Kimera-Semantics支持新的传感器深度相机、激光雷达集成指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考