Cline 桌面端实验分支与 Beta 发布通道desktop-experimental 分支模型、Cline Beta 应用与自动更新源隔离机制【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline本文基于 Cline 仓库中的 desktop-app/EXPERIMENTAL.md 完整展开它定义了 Cline 桌面端的实验功能如何在desktop-experimental长期分支上孵化、如何以独立应用 Cline Beta 的形式通过desktop-beta滚动发布源推送到用户以及如何“毕业”进入main稳定通道。读完后你将掌握双通道stable/beta的分支与标签约定、手动发布 Beta 的完整四步操作、从main调度工作流的安全不变量以及防止更新源串线的三层护栏设计并能直接对照仓库中的工作流与配置文件核验每个环节。一、Beta 通道是什么一个独立应用而不是稳定版的一个开关Cline 桌面端的 beta 不是一个测试模式而是一个完全独立的应用核心特征如下来源EXPERIMENTAL.md What the beta channel is 一节独立的产品名与包标识beta 应用产品名为Cline Betabundle identifier 为bot.cline.app.beta稳定版为Cline/bot.cline.app。这一差异由 src-tauri/tauri.beta.conf.json 在构建时叠加到 tauri.release.conf.json 之上实现{ $schema: https://schema.tauri.app/config/2, productName: Cline Beta, identifier: bot.cline.app.beta, plugins: { updater: { endpoints: [ https://github.com/cline/cline/releases/download/desktop-beta/latest.json ] } } }对比之下稳定版的 tauri.conf.json 中productName为Cline、identifier为bot.cline.appupdater endpoints 指向desktop-latest/latest.json当前仓库版本号为0.0.22可视为版本字段的格式参考。两个应用可并行安装由于包标识不同Cline Beta 与 Cline 在系统里并存用户可以直观地对比 beta 特性与稳定版行为。各通道轮询自己的自动更新源稳定版安装轮询滚动的desktop-latest发布beta 安装轮询滚动的desktop-beta发布。更新源 URL 在编译期就写死进二进制Tauri updater 的 endpoints 配置经代码生成内嵌因此一个 beta 安装只会收到 beta 构建反之亦然。文档明确给出警告两个滚动发布rolling release永远不要删除。命名不对称是有意为之desktop-latest就是稳定源不要把它改名为desktop-stable——因为 URL 已烧录进历史上发布过的每一个稳定版二进制且 updater 没有回退端点重命名或删除会让所有存量安装永久停留在一个死源上。同理desktop-beta在第一个 beta 发布后也适用该规则。共享~/.cline用户目录两个应用共享 provider 凭证、全局设置与 hub 守护进程——hub 本身设计为多客户端与 CLI 应用同时运行是同一模式。若某个 beta 要求更新版本的 hub 构建可能在稳定版应用中触发 hub-update-required 流程反之亦然这属于预期的版本偏斜不是缺陷。用户加入 beta 的方式是从其 GitHub 发布页Slack 上公告下载 beta DMG。系统没有自动降级退出 beta 就是删掉 beta 应用稳定版从未被动过beta 用户则通过其仍安装着的稳定版的常规稳定发布获得已毕业特性的稳定版本。desktop-app/README.md 的 Releases Auto-Updates 一节也从稳定版视角呼应了这一点安装的应用通过 Tauri updater 在启动时及每 2 小时轮询滚动desktop-latest发布里的latest.json后台安装更新并提示重启两样东西绝不能丢——desktop-latest发布/标签以及 updater 私钥TAURI_SIGNING_PRIVATE_KEY没有它已发布应用无法校验新更新。二、分支模型desktop-experimental 的孵化—毕业—单向同步desktop-experimental是一条长期分支实验特性在此回火后再毕业到main。EXPERIMENTAL.md 定义的规则有四条特性 PR 以desktop-experimental为目标在那里合并迭代。特性对main的原始 PR 保持打开但设为draft——它持续累积实验分支上的后续工作并作为意图毕业的文档。毕业Graduation 面向main的新 PR或更新后的那个 draft PR内容包含该特性加上在实验分支上学到的全部东西。按普通mainPR 对待完整评审、完整测试、不带任何实验性脚手架。同步是单向的定期把main合并进desktop-experimental——至少每次稳定版桌面发布之后——使分支不致漂移过远。永远不要把desktop-experimental整体合并回main。同步main进来之时的冲突解决策略package.json/src-tauri/tauri.conf.json的版本号保留实验分支的 beta 版本何时提升其基准见下文版本规则CHANGELOG.md保留两侧章节最新版本在前——稳定版与 beta 章节按新旧交错特性代码凡是已毕业的内容main侧获胜朝main已评审的形态解决。这套模型与 README.md 中描述的发布流水线完全衔接两个通道共用同一个desktop-publish工作流只是channel输入不同详见第四节。三、版本与标签约定版本号规则确保两个通道在 semver 意义上始终保持有序Beta 版本是下一个稳定版的预发布稳定版0.0.13在发时beta 序列为0.0.14-beta.1、0.0.14-beta.2、……标签格式desktop-vX.Y.Z-beta.N打在desktop-experimental上的某个提交上稳定版标签无后缀的desktop-vX.Y.Z留在main上。工作流会校验两种标签形状以及各自通道的分支祖先关系validatejob见 desktop-publish.yml。基准抬升规则当某个版本 ≥ 当前 beta 基准的稳定版发布后下一个 beta 要抬升基准稳定版0.0.14发出 → 下一个 beta 是0.0.15-beta.1。一个 beta 永远不能与已发布的稳定版共享同一个X.Y.Z基准。semver 保持通道有序0.0.14-beta.N排在稳定版0.0.13之上、最终0.0.14之下。publish-desktop 技能文件 进一步给出了版本源的工程细节版本号有两个必须互相一致的来源——apps/examples/desktop-app/package.json 与 src-tauri/tauri.conf.jsonsrc-tauri/Cargo.toml也有自己的版本但会被tauri.conf.json覆盖无需改动工作流的validatejob 会同时比对标签、两个版本文件与检出提交的一致性desktop-publish.yml。四、发布一个 Beta四步手动流程Beta 发布是手动的与稳定版相同没有夜间自动化。EXPERIMENTAL.md 给出简短流程完整版在 publish-desktop 技能 中在desktop-experimental上合并main进来把两个版本文件package.json和src-tauri/tauri.conf.json抬升到新的 beta 版本在 CHANGELOG.md 顶部追加## X.Y.Z-beta.N章节提交并推送。在该提交上打标签desktop-vX.Y.Z-beta.N并推送标签。从main调度beta 通道gh workflow run desktop-publish.yml --ref main \ -f git_tagdesktop-vX.Y.Z-beta.N \ -f channelbeta \ -f confirm_publishpublish批准PublishDesktop环境门工作流随后构建、签名、公证 beta 包创建一个prerelease的 GitHub 发布刷新desktop-beta/latest.json并向 Slack 发公告——与稳定版同一公告路径但标记为 beta。工作流侧的对应实现在 desktop-publish.yml 中可逐条核对workflow_dispatch输入包含git_tag必填、confirm_publish须填publish、channelchoice选项stable/beta默认stablevalidatejob 对 beta 通道做 fail-closed 映射标签须匹配^desktop-v[0-9]\.[0-9]\.[0-9]-beta\.[0-9]$ANCESTOR_REFdesktop-experimental即标签提交必须可从origin/desktop-experimental到达FEEDdesktop-beta产品名Cline Betadesktop-publish.ymlbuildjob 对 beta 额外叠加配置bunx tauri build --target universal-apple-darwin $CONFIG_ARGS其中 beta 的CONFIG_ARGS为--config src-tauri/tauri.release.conf.json --config src-tauri/tauri.beta.conf.json——Tauri 按顺序合并重复的--configbeta 叠加层产品名、包标识、beta 更新源覆盖在 release 层之上desktop-publish.yml。publish-desktop 技能 还补充了两个稳定版没有强调的 beta 专属验证动作beta 发布成功后应确认稳定源未被触碰——desktop-latest/latest.json仍须提供上一个稳定版工作流 fail-closed 地防护这一点但人工核验成本很低、错过则后果严重且validate通过后运行会停在waiting状态等待PublishDesktop环境审批这是预期行为而非挂起。五、为什么代码在 desktop-experimental却要从 main 调度这是 EXPERIMENTAL.md 中最具安全工程价值的一节值得完整理解。安全不变量工作流运行执行的是main上的那份desktop-publish.yml只有checkout指向 beta 标签validatejob 通过祖先检查把标签钉在desktop-experimental谱系上。于是针对稳定版的全部签名密钥门原封不动地适用于 betabuildjob 的if: github.ref refs/heads/main检查desktop-publish.ymlPublishDesktop环境的 main-only deployment-branch 策略desktop-publish.yml。在desktop-experimental上被编辑过的工作流文件永远无法触达签名密钥。文档因此给出硬性禁令不要把desktop-experimental加进 PublishDesktop 的 deployment-branch 策略。工作流源码中的大段注释与这条禁令逐字呼应desktop-publish.yml。但从 main 调度覆盖不到的风险也要如实理解buildjob 会检出标签并运行它自带的构建脚本依赖安装钩子、build:sdk、Tauri 的beforeBuildCommand、build.rs且此时签名密钥在作用域内——稳定版与 beta 皆如此。对此的控制手段是PublishDesktop的必需评审人审批批准一次发布意味着为该标签所指的代码背书而不只是为发生了一次发布背书。这正是desktop-experimental必须维持 main 级合并控制分支保护、仅维护者可推送的原因——任何能把代码落到那条分支上的人都能在一次发布获批后让那段代码与签名密钥同场运行。此外validatejob 还有一道针对密钥作用域的检查它在不声明任何 environment的 job 里探测签名密钥是否可解析——若可解析说明密钥仍以仓库/组织级 secret 存在对仓库内所有工作流可见运行直接失败提示把密钥迁移到PublishDesktop环境desktop-publish.yml。publish-desktop 技能 也把这列为常见错误把签名密钥加为仓库级 secret 不会让构建失败环境门控的 job 同样能解析仓库 secret环境值只是优先密钥就会在一切看似正常的前提下暴露在整个仓库范围。六、护栏更新源隔离是整个安全故事的承重墙updater 的比较器只是朴素的 semver大于即更新更新源之间的隔离就是全部的安全叙事一份落在desktop-latest上的 beta 清单会把每一个稳定版安装自动更新到 beta 上。EXPERIMENTAL.md 指出工作流以三种方式防护这一点均能在源码中定位稳定通道拒绝预发布标签stable 的标签正则不含-beta.N后缀desktop-publish.yml更新源目标由通道 fail-closed 推导并在 release job 交叉复核validate输出feedrelease job 再按channel重算一次期望的 feedstable →desktop-latestbeta →desktop-beta并强制一致不一致即 feed mismatch 失败desktop-publish.yml构建产物断言任何内容被签入发布之前构建阶段用strings扫描 bundle 内的每个二进制断言其恰好嵌入本通道的 feed URLstable 必须含desktop-latest/latest.json且不得含desktop-beta/latest.jsonbeta 反之防止某个--config叠加层静默失效desktop-publish.ymlWindows 构建有对应的同款检查desktop-publish.yml。最后一条护栏直接对应 tauri.beta.conf.json 中的 endpoints 配置——更新端点作为字符串字面量被 tauri-build 经代码生成内嵌进主二进制因此可以用strings精确核验。配套规则tauri.beta.conf.json必须存在于被打标签的提交上因为构建检出的是标签所以要把它同时保留在main和desktop-experimental上。当前仓库两个配置层的分工也清晰tauri.conf.json 承载产品定义与稳定源tauri.release.conf.json 仅开启bundle.createUpdaterArtifactstauri.beta.conf.json 承载 beta 产品身份与 beta 源。七、要点速查事项规则依据Beta 应用身份Cline Beta/bot.cline.app.beta叠加tauri.beta.conf.jsontauri.beta.conf.json更新源稳定desktop-latestbetadesktop-betaURL 编译期内嵌滚动发布永不删除EXPERIMENTAL.md分支同步方向仅main→desktop-experimental至少每次稳定发布后同步EXPERIMENTAL.md毕业方式面向main的新 PR或更新的 draft PR按普通 main PR 评审EXPERIMENTAL.mdBeta 版本下一稳定版的预发布基准不得与已发稳定版重复EXPERIMENTAL.md、SKILL.md调度方式两个通道都从main调度beta 标签钉在desktop-experimental谱系desktop-publish.yml审批语义批准发布 为标签所指代码背书desktop-experimental保持 main 级合并控制desktop-publish.yml对需要动手操作发布的读者完整的命令级流程含上下文收集、changelog 起草、版本决策、提交与验证、发布后源校验以 publish-desktop 技能 为准它声明的工作目录约定是仓库根目录并明确两个通道都从main调度是安全不变量而非便利选择。桌面端发布、签名与公证的一次性配置则见 desktop-app/README.md 的 macOS signing notarization, step by step 一节。【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cline 桌面端实验分支与 Beta 发布通道：desktop-experimental 分支模型、Cline Beta 应用与自动更新源隔离机制
Cline 桌面端实验分支与 Beta 发布通道desktop-experimental 分支模型、Cline Beta 应用与自动更新源隔离机制【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline本文基于 Cline 仓库中的 desktop-app/EXPERIMENTAL.md 完整展开它定义了 Cline 桌面端的实验功能如何在desktop-experimental长期分支上孵化、如何以独立应用 Cline Beta 的形式通过desktop-beta滚动发布源推送到用户以及如何“毕业”进入main稳定通道。读完后你将掌握双通道stable/beta的分支与标签约定、手动发布 Beta 的完整四步操作、从main调度工作流的安全不变量以及防止更新源串线的三层护栏设计并能直接对照仓库中的工作流与配置文件核验每个环节。一、Beta 通道是什么一个独立应用而不是稳定版的一个开关Cline 桌面端的 beta 不是一个测试模式而是一个完全独立的应用核心特征如下来源EXPERIMENTAL.md What the beta channel is 一节独立的产品名与包标识beta 应用产品名为Cline Betabundle identifier 为bot.cline.app.beta稳定版为Cline/bot.cline.app。这一差异由 src-tauri/tauri.beta.conf.json 在构建时叠加到 tauri.release.conf.json 之上实现{ $schema: https://schema.tauri.app/config/2, productName: Cline Beta, identifier: bot.cline.app.beta, plugins: { updater: { endpoints: [ https://github.com/cline/cline/releases/download/desktop-beta/latest.json ] } } }对比之下稳定版的 tauri.conf.json 中productName为Cline、identifier为bot.cline.appupdater endpoints 指向desktop-latest/latest.json当前仓库版本号为0.0.22可视为版本字段的格式参考。两个应用可并行安装由于包标识不同Cline Beta 与 Cline 在系统里并存用户可以直观地对比 beta 特性与稳定版行为。各通道轮询自己的自动更新源稳定版安装轮询滚动的desktop-latest发布beta 安装轮询滚动的desktop-beta发布。更新源 URL 在编译期就写死进二进制Tauri updater 的 endpoints 配置经代码生成内嵌因此一个 beta 安装只会收到 beta 构建反之亦然。文档明确给出警告两个滚动发布rolling release永远不要删除。命名不对称是有意为之desktop-latest就是稳定源不要把它改名为desktop-stable——因为 URL 已烧录进历史上发布过的每一个稳定版二进制且 updater 没有回退端点重命名或删除会让所有存量安装永久停留在一个死源上。同理desktop-beta在第一个 beta 发布后也适用该规则。共享~/.cline用户目录两个应用共享 provider 凭证、全局设置与 hub 守护进程——hub 本身设计为多客户端与 CLI 应用同时运行是同一模式。若某个 beta 要求更新版本的 hub 构建可能在稳定版应用中触发 hub-update-required 流程反之亦然这属于预期的版本偏斜不是缺陷。用户加入 beta 的方式是从其 GitHub 发布页Slack 上公告下载 beta DMG。系统没有自动降级退出 beta 就是删掉 beta 应用稳定版从未被动过beta 用户则通过其仍安装着的稳定版的常规稳定发布获得已毕业特性的稳定版本。desktop-app/README.md 的 Releases Auto-Updates 一节也从稳定版视角呼应了这一点安装的应用通过 Tauri updater 在启动时及每 2 小时轮询滚动desktop-latest发布里的latest.json后台安装更新并提示重启两样东西绝不能丢——desktop-latest发布/标签以及 updater 私钥TAURI_SIGNING_PRIVATE_KEY没有它已发布应用无法校验新更新。二、分支模型desktop-experimental 的孵化—毕业—单向同步desktop-experimental是一条长期分支实验特性在此回火后再毕业到main。EXPERIMENTAL.md 定义的规则有四条特性 PR 以desktop-experimental为目标在那里合并迭代。特性对main的原始 PR 保持打开但设为draft——它持续累积实验分支上的后续工作并作为意图毕业的文档。毕业Graduation 面向main的新 PR或更新后的那个 draft PR内容包含该特性加上在实验分支上学到的全部东西。按普通mainPR 对待完整评审、完整测试、不带任何实验性脚手架。同步是单向的定期把main合并进desktop-experimental——至少每次稳定版桌面发布之后——使分支不致漂移过远。永远不要把desktop-experimental整体合并回main。同步main进来之时的冲突解决策略package.json/src-tauri/tauri.conf.json的版本号保留实验分支的 beta 版本何时提升其基准见下文版本规则CHANGELOG.md保留两侧章节最新版本在前——稳定版与 beta 章节按新旧交错特性代码凡是已毕业的内容main侧获胜朝main已评审的形态解决。这套模型与 README.md 中描述的发布流水线完全衔接两个通道共用同一个desktop-publish工作流只是channel输入不同详见第四节。三、版本与标签约定版本号规则确保两个通道在 semver 意义上始终保持有序Beta 版本是下一个稳定版的预发布稳定版0.0.13在发时beta 序列为0.0.14-beta.1、0.0.14-beta.2、……标签格式desktop-vX.Y.Z-beta.N打在desktop-experimental上的某个提交上稳定版标签无后缀的desktop-vX.Y.Z留在main上。工作流会校验两种标签形状以及各自通道的分支祖先关系validatejob见 desktop-publish.yml。基准抬升规则当某个版本 ≥ 当前 beta 基准的稳定版发布后下一个 beta 要抬升基准稳定版0.0.14发出 → 下一个 beta 是0.0.15-beta.1。一个 beta 永远不能与已发布的稳定版共享同一个X.Y.Z基准。semver 保持通道有序0.0.14-beta.N排在稳定版0.0.13之上、最终0.0.14之下。publish-desktop 技能文件 进一步给出了版本源的工程细节版本号有两个必须互相一致的来源——apps/examples/desktop-app/package.json 与 src-tauri/tauri.conf.jsonsrc-tauri/Cargo.toml也有自己的版本但会被tauri.conf.json覆盖无需改动工作流的validatejob 会同时比对标签、两个版本文件与检出提交的一致性desktop-publish.yml。四、发布一个 Beta四步手动流程Beta 发布是手动的与稳定版相同没有夜间自动化。EXPERIMENTAL.md 给出简短流程完整版在 publish-desktop 技能 中在desktop-experimental上合并main进来把两个版本文件package.json和src-tauri/tauri.conf.json抬升到新的 beta 版本在 CHANGELOG.md 顶部追加## X.Y.Z-beta.N章节提交并推送。在该提交上打标签desktop-vX.Y.Z-beta.N并推送标签。从main调度beta 通道gh workflow run desktop-publish.yml --ref main \ -f git_tagdesktop-vX.Y.Z-beta.N \ -f channelbeta \ -f confirm_publishpublish批准PublishDesktop环境门工作流随后构建、签名、公证 beta 包创建一个prerelease的 GitHub 发布刷新desktop-beta/latest.json并向 Slack 发公告——与稳定版同一公告路径但标记为 beta。工作流侧的对应实现在 desktop-publish.yml 中可逐条核对workflow_dispatch输入包含git_tag必填、confirm_publish须填publish、channelchoice选项stable/beta默认stablevalidatejob 对 beta 通道做 fail-closed 映射标签须匹配^desktop-v[0-9]\.[0-9]\.[0-9]-beta\.[0-9]$ANCESTOR_REFdesktop-experimental即标签提交必须可从origin/desktop-experimental到达FEEDdesktop-beta产品名Cline Betadesktop-publish.ymlbuildjob 对 beta 额外叠加配置bunx tauri build --target universal-apple-darwin $CONFIG_ARGS其中 beta 的CONFIG_ARGS为--config src-tauri/tauri.release.conf.json --config src-tauri/tauri.beta.conf.json——Tauri 按顺序合并重复的--configbeta 叠加层产品名、包标识、beta 更新源覆盖在 release 层之上desktop-publish.yml。publish-desktop 技能 还补充了两个稳定版没有强调的 beta 专属验证动作beta 发布成功后应确认稳定源未被触碰——desktop-latest/latest.json仍须提供上一个稳定版工作流 fail-closed 地防护这一点但人工核验成本很低、错过则后果严重且validate通过后运行会停在waiting状态等待PublishDesktop环境审批这是预期行为而非挂起。五、为什么代码在 desktop-experimental却要从 main 调度这是 EXPERIMENTAL.md 中最具安全工程价值的一节值得完整理解。安全不变量工作流运行执行的是main上的那份desktop-publish.yml只有checkout指向 beta 标签validatejob 通过祖先检查把标签钉在desktop-experimental谱系上。于是针对稳定版的全部签名密钥门原封不动地适用于 betabuildjob 的if: github.ref refs/heads/main检查desktop-publish.ymlPublishDesktop环境的 main-only deployment-branch 策略desktop-publish.yml。在desktop-experimental上被编辑过的工作流文件永远无法触达签名密钥。文档因此给出硬性禁令不要把desktop-experimental加进 PublishDesktop 的 deployment-branch 策略。工作流源码中的大段注释与这条禁令逐字呼应desktop-publish.yml。但从 main 调度覆盖不到的风险也要如实理解buildjob 会检出标签并运行它自带的构建脚本依赖安装钩子、build:sdk、Tauri 的beforeBuildCommand、build.rs且此时签名密钥在作用域内——稳定版与 beta 皆如此。对此的控制手段是PublishDesktop的必需评审人审批批准一次发布意味着为该标签所指的代码背书而不只是为发生了一次发布背书。这正是desktop-experimental必须维持 main 级合并控制分支保护、仅维护者可推送的原因——任何能把代码落到那条分支上的人都能在一次发布获批后让那段代码与签名密钥同场运行。此外validatejob 还有一道针对密钥作用域的检查它在不声明任何 environment的 job 里探测签名密钥是否可解析——若可解析说明密钥仍以仓库/组织级 secret 存在对仓库内所有工作流可见运行直接失败提示把密钥迁移到PublishDesktop环境desktop-publish.yml。publish-desktop 技能 也把这列为常见错误把签名密钥加为仓库级 secret 不会让构建失败环境门控的 job 同样能解析仓库 secret环境值只是优先密钥就会在一切看似正常的前提下暴露在整个仓库范围。六、护栏更新源隔离是整个安全故事的承重墙updater 的比较器只是朴素的 semver大于即更新更新源之间的隔离就是全部的安全叙事一份落在desktop-latest上的 beta 清单会把每一个稳定版安装自动更新到 beta 上。EXPERIMENTAL.md 指出工作流以三种方式防护这一点均能在源码中定位稳定通道拒绝预发布标签stable 的标签正则不含-beta.N后缀desktop-publish.yml更新源目标由通道 fail-closed 推导并在 release job 交叉复核validate输出feedrelease job 再按channel重算一次期望的 feedstable →desktop-latestbeta →desktop-beta并强制一致不一致即 feed mismatch 失败desktop-publish.yml构建产物断言任何内容被签入发布之前构建阶段用strings扫描 bundle 内的每个二进制断言其恰好嵌入本通道的 feed URLstable 必须含desktop-latest/latest.json且不得含desktop-beta/latest.jsonbeta 反之防止某个--config叠加层静默失效desktop-publish.ymlWindows 构建有对应的同款检查desktop-publish.yml。最后一条护栏直接对应 tauri.beta.conf.json 中的 endpoints 配置——更新端点作为字符串字面量被 tauri-build 经代码生成内嵌进主二进制因此可以用strings精确核验。配套规则tauri.beta.conf.json必须存在于被打标签的提交上因为构建检出的是标签所以要把它同时保留在main和desktop-experimental上。当前仓库两个配置层的分工也清晰tauri.conf.json 承载产品定义与稳定源tauri.release.conf.json 仅开启bundle.createUpdaterArtifactstauri.beta.conf.json 承载 beta 产品身份与 beta 源。七、要点速查事项规则依据Beta 应用身份Cline Beta/bot.cline.app.beta叠加tauri.beta.conf.jsontauri.beta.conf.json更新源稳定desktop-latestbetadesktop-betaURL 编译期内嵌滚动发布永不删除EXPERIMENTAL.md分支同步方向仅main→desktop-experimental至少每次稳定发布后同步EXPERIMENTAL.md毕业方式面向main的新 PR或更新的 draft PR按普通 main PR 评审EXPERIMENTAL.mdBeta 版本下一稳定版的预发布基准不得与已发稳定版重复EXPERIMENTAL.md、SKILL.md调度方式两个通道都从main调度beta 标签钉在desktop-experimental谱系desktop-publish.yml审批语义批准发布 为标签所指代码背书desktop-experimental保持 main 级合并控制desktop-publish.yml对需要动手操作发布的读者完整的命令级流程含上下文收集、changelog 起草、版本决策、提交与验证、发布后源校验以 publish-desktop 技能 为准它声明的工作目录约定是仓库根目录并明确两个通道都从main调度是安全不变量而非便利选择。桌面端发布、签名与公证的一次性配置则见 desktop-app/README.md 的 macOS signing notarization, step by step 一节。【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考