编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载导读本文基于 Dart SDK 官方发布流程文档系统讲解如何将一个已经在main分支上修复的 bug通过 cherry-pick遴选机制合入beta或stable发布分支从而进入下一个热修复hotfix版本。读完本文你将掌握完整的 cherry-pick 操作链路判断是否需要回移、创建与提交遴选变更列表changelist、编写合规的提交信息与 CHANGELOG 条目、通过 Gerrit 提交队列上线以及当修复涉及third_party依赖时的特殊处理流程。文档对应的原始资料位于 docs/Cherry-picks-to-a-release-channel.md。一、什么是 Cherry-pick从 main 到发布分支的定向修复Cherry-picking 指的是从主开发分支main中挑选一个已经存在的 bug 修复提交将其合并到发布分支如beta、stable以便纳入下一个热修复版本的发布流程。Dart SDK 采用多分支并行开发与发布模型docs/Branches-and-releases.md 中给出了清晰的分支职责划分main日常开发主干所有 CL 在此落地dev由 main 全量推送填充通常每周两次仅紧急情况才使用 cherry-pickbeta由 dev 全量推送或通过 cherry-pick 填充通常每月一次不要直接在此提交 CLstable主发布分支由 beta 全量推送或 cherry-pick 填充同样禁止直接落地 CL。重要前提cherry-pick 流程仅适用于 bug 修复和回归regression修复。新功能feature work不在此流程考虑范围内需要等待下一个正式版本发布。每次发布周期的最后约两周会进入所谓 cherry-pick season热修复季此时对 beta 通道只遴选关键修复每周可能产生多批 cherry-pick。二、第一步判断一个修复是否需要 Cherry-pick触发 cherry-pick 的完整判断流程如下解决 issue 并在 main 分支落地修复同时附带测试以确认问题确实被修复确认问题是否存在于最新的 beta 与 stable 版本中评估修复是否值得回移backport如果两个通道beta 和 stable都受影响则可能需要提交两份 changelist分别针对 beta 和 stable。只有经过上述评估确认值得回移的修复才进入正式的 cherry-pick 操作。三、核心操作如何 Cherry-pick 一个 Changelist3.1 创建遴选分支并执行提交遴选在 SDK 检出目录中将目标提交$commit遴选到一个以origin/stable或origin/beta为上游的新分支$ git fetch $ git new-branch --upstream origin/stable cherry # 或 origin/beta $ git cherry-pick --edit $commit $ $EDITOR CHANGELOG.md # 仅 stable 需要详见下文其中git new-branch是 Google 的 depot_tools/git 辅助命令用于创建并切换到以origin/stable为上游的新分支cherrygit cherry-pick --edit在应用提交的同时打开编辑器强制你修订提交信息这正是提交信息合规所必需的如果同时面向 beta 和 stable 两个通道则需要在两个分支上分别执行上述流程。3.2 修订提交信息四个必改项遴选后的提交信息必须按以下规则修订在第一行行首添加[beta]或[stable]Gerrit 主题标签hashtag以便评审者一眼识别这是面向发布分支的遴选将原提交的Reviewed-on字段重命名为Cherry-pick用于链接到被遴选的原始 changelist删除新 changelist 中不成立的冲突字段Change-id、Commit-queue、Reviewed-by在描述中补充以下五段信息Issue description问题描述问题是什么影响哪些平台What is the fix修复内容简述Why cherry-pick说明回移理由、受影响用户与功能性问题Risk本次遴选伴随的风险Issue link(s)原始 issue 的链接3.3 提交信息示例[stable] Fix foo crash. Issue description: When attempting to use foo under certain conditions, users are unable to compile. What is the fix: foo is now evaluated at runtime. Why cherry-pick: Users of foo are no longer able to compile to bar. Risk: Low, this fix has landed on the main channel and is tested on the same infrastructure. Issue link(s): https://github.com/dart-lang/sdk/issues/12345678 Cherry-pick: https://dart-review.googlesource.com/c/sdk//123456783.4 Gerrit 侧元数据要求Gerrit-Submit-Requirements.md 从评审系统角度进一步补充了元数据规范面向 stable 和 beta 分支的所有 CL 都要走 cherry-pick 审批流程提交信息必须包含[stable]或[beta]hashtagCherry-pickfooter 必须链接到 main 分支上的原始评审若一次遴选捆绑了多个变更可多次使用该 footer如果该变更是原创而非从 main 遴选则需要说明原创理由——footer 的目的是帮助评审者理解原始变更、确认其在发布分支上是安全的Cherry-pick-requestfooter 必须链接到批准该遴选理由的 GitHub issue用于在提交前确认已获得批准提交信息中不得保留原提交的Reviewed-on、Reviewed-by、Commit-Queuefooters新的 footers 会在提交时自动生成。四、CHANGELOGstable 遴选的强制要求4.1 为什么必须写stable 通道的 cherry-pick必须在 CHANGELOG.md 中添加条目说明变更内容。原因很直接发布工程师没有你的全部上下文他们依赖 CHANGELOG 来撰写发布说明。beta 版本则不需要changelog 条目。如果CHANGELOG.md中还没有下一个 stable 热修复版本的小节需要新增一个小节并递增补丁号例如3.0.4→3.0.5不写日期。如果某个小节已带有发布日期说明该版本已经发布不应再修改——发布日期会在 stable 版本正式编写、确定发布时间时补上。4.2 标准条目格式## 3.0.5 This is a patch release that: - Fixes all bugs in the Dart SDK (issue [#123456]) [#123456]: https://dart-review.googlesource.com/c/sdk//123456 ## 3.0.4 **Released on:** 2025-01-08 This is a patch release that: ...4.3 豁免情况如果该遴选仅涉及基础设施、对用户不可见可以使用Changelog-Exempt: ...footer 豁免 changelog 要求。同样地Gerrit-Submit-Requirements.md 中说明基础设施类对用户不可见的变更可用Changelog-Exempt: ...说明为何不需要 CHANGELOG 条目。版本号侧证仓库中的 tools/VERSION 文件注释记录了版本演进规则——Making cherry-picks to stable channel 时递增PATCH即3.0.4→3.0.5Doing a cherry-pick to trunk 时递增PRERELEASE_PATCH。这从版本管理层面印证了本文档描述的补丁号递增规则。五、上传与提交Gerrit 评审与提交队列5.1 上传 changelist使用 depot_tools 的上传命令将遴选 changelist 提交到 Gerrit 等待审批git cl upload上传后先触发一次commit queue 干跑dry run并添加合适的 try builders以确认修复在发布分支上是正确的。5.2 提交与回归防护遴选 changelist 需经过**领域主题专家area subject matter expert与Dart 团队负责人Dart team lead**的双重评审后由遴选作者提交到 commit queue。提交队列的 try jobs 会将测试结果与 beta/stable 分支上的上一个提交进行对比一旦引入任何回归即判定失败。特殊情形如果必须引入回归或 try builders 无法在较旧的 beta/stable 代码上运行可以绕过提交队列在 Gerrit 中通过强制提交... - Submit完成上线。六、进阶场景Cherry-pick 依赖仓库中的单个提交当修复涉及third_party下的依赖仓库例如third-party/pkg/pub中的单个提交时流程有所不同需要先在依赖仓库中完成遴选、推送再通过 SDK 的 DEPS 版本提升bump机制把发布分支指向新提交。6.1 在 SDK 检出中定位依赖当前修订dart-sdk/sdk/ git checkout beta git pull dart-sdk/sdk/ gclient getdep -r sdk/third_party/pkg/pub a3f8b2fd36ec432450caf907474a02023ef3e44e6.2 在依赖仓库中创建遴选并推送pub/ git checkout -b cherry-pick a3f8b2fd36ec432450caf907474a02023ef3e44e pub/ git cherry-pick $commit-to-cherry-pick pub/ git push -u origin cherry_pick:cherry_pick pub/ git rev-parse HEAD 6d1857c84cfb8a014aefedaf2d453214bf5ddb96 # -- 这就是我们要移动到的修订版本推送后需要等待片刻让变更镜像到 dart.googlesource.com。6.3 将遴选提交合并进受保护分支必须确保依赖上的遴选提交被合并进受保护分支这里指main否则存在被垃圾回收GC的风险。下面的脚本可以创建这样的合并#!/bin/bash BRANCHname of branch to merge REPOname of repository # Defaults that may need to be changed. TARGET_BRANCHmain # sometimes repositories use a different default branch. ORGdart-lang # most dependencies are in dart-lang, but not all. REMOTEorigin # use upstream if that is the target repos remote. # Clone the repo if you dont already have a clone. gh repo clone $ORG/$REPO # Switch to the repos directory. cd $REPO # Fetch and create a branch tracking the target branch. git fetch $REMOTE git switch -c merge-$BRANCH $REMOTE/$TARGET_BRANCH # Create a merge commit. git merge -sours $REMOTE/$BRANCH gh pr create为这个合并创建 PR 时务必选择merge合并提交而不是 squash压缩合并——必要时可能需要临时调整仓库设置才能做到。6.4 在 SDK 检出中提升 DEPS 版本并上传 CL回到 SDK 检出目录使用tools/manage_deps.dart创建一个 bump 提交和一个将发布通道移动到新遴选提交注意是遴选提交而非合并提交的 CLdart-sdk/sdk/ tools/manage_deps.dart bump third_party/pkg/pub --target6d1857c84cfb8a014aefedaf2d453214bf5ddb96然后将该 CL 改为相对于发布通道dart-sdk/sdk/ git branch --set-upstream-toorigin/beta dart-sdk/sdk/ git cl upload这个 CL 即可直接用于上文所述的 cherry-pick 流程。源码侧证tools/manage_deps.dart 的实现印证了上述流程bump命令会先检查 git 工作区是否干净、创建bump_dependency分支、通过gclient getdep -r sdk/dependency找到当前修订、再用gclient setdep -r sdk/dependencytarget更新 DEPS 中对应的依赖条目并同步依赖最后创建带git log的提交并提示创建 CL。而 DEPS 中Var(dart_root) /third_party/pkg/pub一栏正对应Var(dart_git) pub.git Var(pub_rev)即每个依赖修订号最终以revision形式固化在 DEPS 文件中。七、常见注意事项与要点速查环节关键要求适用范围仅 bug 与回归修复新功能等待下一版本目标分支origin/beta或origin/stable禁止直接落地 CL提交信息首行加[beta]/[stable]Reviewed-on改名为Cherry-pick删除Change-id/Commit-queue/Reviewed-by描述字段Issue description / What is the fix / Why cherry-pick / Risk / Issue link(s)CHANGELOGstable 必须写beta 不写无小节则新增并递增 patch 号不写日期已发布小节不可改豁免对用户不可见的基础设施变更可用Changelog-Exempt: ...评审与提交领域专家 团队负责人评审commit queue 对比上一提交防回归必要时可强制提交依赖遴选先在依赖仓库推送遴选合并进其默认分支再manage_deps.dart bump提升 SDK 依赖版本版本号联动stable cherry-pick 递增 PATCH见 tools/VERSION 注释规则掌握上述流程后无论是 SDK 自身代码的紧急修复还是third_party依赖中的关键补丁都能安全、合规地进入 beta/stable 热修复版本第一时间交付给受影响的用户。赞分享编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载相关推荐rsuite-table源码解析深入理解高性能表格组件的实现原理rsuite table源码解析深入理解高性能表格组件的实现原理 rsuite table是一个功能强大的React表格组件库专为处理大规模数据而设计。作为桌面应用富文本Flutter 构建发布渠道build/release channels全解析master、beta、stable 的选择、切换与热修复流程Flutter 构建发布渠道build/release channels全解析master、beta、stable 的选择、切换与热修复流程 Flutte跨平台移动开发前端UI组件桌面应用Realm Swift SDK 发布流程全指南master 正式版、分支预发布与热修复补丁的完整发布手册Realm Swift SDK 发布流程全指南master 正式版、分支预发布与热修复补丁的完整发布手册 导读 本文以仓库 contrib/ReleasePr数据库移动开发嵌入式数据库上一篇Vue.Draggable组件状态管理性能分析Chrome DevTools下一篇CRI-O多运行时支持终极指南如何在同一个Kubernetes集群中灵活切换不同OCI运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dart SDK 发布渠道 Cherry-pick 全流程指南：从修复落地到 stable/beta 热修复发布
编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载导读本文基于 Dart SDK 官方发布流程文档系统讲解如何将一个已经在main分支上修复的 bug通过 cherry-pick遴选机制合入beta或stable发布分支从而进入下一个热修复hotfix版本。读完本文你将掌握完整的 cherry-pick 操作链路判断是否需要回移、创建与提交遴选变更列表changelist、编写合规的提交信息与 CHANGELOG 条目、通过 Gerrit 提交队列上线以及当修复涉及third_party依赖时的特殊处理流程。文档对应的原始资料位于 docs/Cherry-picks-to-a-release-channel.md。一、什么是 Cherry-pick从 main 到发布分支的定向修复Cherry-picking 指的是从主开发分支main中挑选一个已经存在的 bug 修复提交将其合并到发布分支如beta、stable以便纳入下一个热修复版本的发布流程。Dart SDK 采用多分支并行开发与发布模型docs/Branches-and-releases.md 中给出了清晰的分支职责划分main日常开发主干所有 CL 在此落地dev由 main 全量推送填充通常每周两次仅紧急情况才使用 cherry-pickbeta由 dev 全量推送或通过 cherry-pick 填充通常每月一次不要直接在此提交 CLstable主发布分支由 beta 全量推送或 cherry-pick 填充同样禁止直接落地 CL。重要前提cherry-pick 流程仅适用于 bug 修复和回归regression修复。新功能feature work不在此流程考虑范围内需要等待下一个正式版本发布。每次发布周期的最后约两周会进入所谓 cherry-pick season热修复季此时对 beta 通道只遴选关键修复每周可能产生多批 cherry-pick。二、第一步判断一个修复是否需要 Cherry-pick触发 cherry-pick 的完整判断流程如下解决 issue 并在 main 分支落地修复同时附带测试以确认问题确实被修复确认问题是否存在于最新的 beta 与 stable 版本中评估修复是否值得回移backport如果两个通道beta 和 stable都受影响则可能需要提交两份 changelist分别针对 beta 和 stable。只有经过上述评估确认值得回移的修复才进入正式的 cherry-pick 操作。三、核心操作如何 Cherry-pick 一个 Changelist3.1 创建遴选分支并执行提交遴选在 SDK 检出目录中将目标提交$commit遴选到一个以origin/stable或origin/beta为上游的新分支$ git fetch $ git new-branch --upstream origin/stable cherry # 或 origin/beta $ git cherry-pick --edit $commit $ $EDITOR CHANGELOG.md # 仅 stable 需要详见下文其中git new-branch是 Google 的 depot_tools/git 辅助命令用于创建并切换到以origin/stable为上游的新分支cherrygit cherry-pick --edit在应用提交的同时打开编辑器强制你修订提交信息这正是提交信息合规所必需的如果同时面向 beta 和 stable 两个通道则需要在两个分支上分别执行上述流程。3.2 修订提交信息四个必改项遴选后的提交信息必须按以下规则修订在第一行行首添加[beta]或[stable]Gerrit 主题标签hashtag以便评审者一眼识别这是面向发布分支的遴选将原提交的Reviewed-on字段重命名为Cherry-pick用于链接到被遴选的原始 changelist删除新 changelist 中不成立的冲突字段Change-id、Commit-queue、Reviewed-by在描述中补充以下五段信息Issue description问题描述问题是什么影响哪些平台What is the fix修复内容简述Why cherry-pick说明回移理由、受影响用户与功能性问题Risk本次遴选伴随的风险Issue link(s)原始 issue 的链接3.3 提交信息示例[stable] Fix foo crash. Issue description: When attempting to use foo under certain conditions, users are unable to compile. What is the fix: foo is now evaluated at runtime. Why cherry-pick: Users of foo are no longer able to compile to bar. Risk: Low, this fix has landed on the main channel and is tested on the same infrastructure. Issue link(s): https://github.com/dart-lang/sdk/issues/12345678 Cherry-pick: https://dart-review.googlesource.com/c/sdk//123456783.4 Gerrit 侧元数据要求Gerrit-Submit-Requirements.md 从评审系统角度进一步补充了元数据规范面向 stable 和 beta 分支的所有 CL 都要走 cherry-pick 审批流程提交信息必须包含[stable]或[beta]hashtagCherry-pickfooter 必须链接到 main 分支上的原始评审若一次遴选捆绑了多个变更可多次使用该 footer如果该变更是原创而非从 main 遴选则需要说明原创理由——footer 的目的是帮助评审者理解原始变更、确认其在发布分支上是安全的Cherry-pick-requestfooter 必须链接到批准该遴选理由的 GitHub issue用于在提交前确认已获得批准提交信息中不得保留原提交的Reviewed-on、Reviewed-by、Commit-Queuefooters新的 footers 会在提交时自动生成。四、CHANGELOGstable 遴选的强制要求4.1 为什么必须写stable 通道的 cherry-pick必须在 CHANGELOG.md 中添加条目说明变更内容。原因很直接发布工程师没有你的全部上下文他们依赖 CHANGELOG 来撰写发布说明。beta 版本则不需要changelog 条目。如果CHANGELOG.md中还没有下一个 stable 热修复版本的小节需要新增一个小节并递增补丁号例如3.0.4→3.0.5不写日期。如果某个小节已带有发布日期说明该版本已经发布不应再修改——发布日期会在 stable 版本正式编写、确定发布时间时补上。4.2 标准条目格式## 3.0.5 This is a patch release that: - Fixes all bugs in the Dart SDK (issue [#123456]) [#123456]: https://dart-review.googlesource.com/c/sdk//123456 ## 3.0.4 **Released on:** 2025-01-08 This is a patch release that: ...4.3 豁免情况如果该遴选仅涉及基础设施、对用户不可见可以使用Changelog-Exempt: ...footer 豁免 changelog 要求。同样地Gerrit-Submit-Requirements.md 中说明基础设施类对用户不可见的变更可用Changelog-Exempt: ...说明为何不需要 CHANGELOG 条目。版本号侧证仓库中的 tools/VERSION 文件注释记录了版本演进规则——Making cherry-picks to stable channel 时递增PATCH即3.0.4→3.0.5Doing a cherry-pick to trunk 时递增PRERELEASE_PATCH。这从版本管理层面印证了本文档描述的补丁号递增规则。五、上传与提交Gerrit 评审与提交队列5.1 上传 changelist使用 depot_tools 的上传命令将遴选 changelist 提交到 Gerrit 等待审批git cl upload上传后先触发一次commit queue 干跑dry run并添加合适的 try builders以确认修复在发布分支上是正确的。5.2 提交与回归防护遴选 changelist 需经过**领域主题专家area subject matter expert与Dart 团队负责人Dart team lead**的双重评审后由遴选作者提交到 commit queue。提交队列的 try jobs 会将测试结果与 beta/stable 分支上的上一个提交进行对比一旦引入任何回归即判定失败。特殊情形如果必须引入回归或 try builders 无法在较旧的 beta/stable 代码上运行可以绕过提交队列在 Gerrit 中通过强制提交... - Submit完成上线。六、进阶场景Cherry-pick 依赖仓库中的单个提交当修复涉及third_party下的依赖仓库例如third-party/pkg/pub中的单个提交时流程有所不同需要先在依赖仓库中完成遴选、推送再通过 SDK 的 DEPS 版本提升bump机制把发布分支指向新提交。6.1 在 SDK 检出中定位依赖当前修订dart-sdk/sdk/ git checkout beta git pull dart-sdk/sdk/ gclient getdep -r sdk/third_party/pkg/pub a3f8b2fd36ec432450caf907474a02023ef3e44e6.2 在依赖仓库中创建遴选并推送pub/ git checkout -b cherry-pick a3f8b2fd36ec432450caf907474a02023ef3e44e pub/ git cherry-pick $commit-to-cherry-pick pub/ git push -u origin cherry_pick:cherry_pick pub/ git rev-parse HEAD 6d1857c84cfb8a014aefedaf2d453214bf5ddb96 # -- 这就是我们要移动到的修订版本推送后需要等待片刻让变更镜像到 dart.googlesource.com。6.3 将遴选提交合并进受保护分支必须确保依赖上的遴选提交被合并进受保护分支这里指main否则存在被垃圾回收GC的风险。下面的脚本可以创建这样的合并#!/bin/bash BRANCHname of branch to merge REPOname of repository # Defaults that may need to be changed. TARGET_BRANCHmain # sometimes repositories use a different default branch. ORGdart-lang # most dependencies are in dart-lang, but not all. REMOTEorigin # use upstream if that is the target repos remote. # Clone the repo if you dont already have a clone. gh repo clone $ORG/$REPO # Switch to the repos directory. cd $REPO # Fetch and create a branch tracking the target branch. git fetch $REMOTE git switch -c merge-$BRANCH $REMOTE/$TARGET_BRANCH # Create a merge commit. git merge -sours $REMOTE/$BRANCH gh pr create为这个合并创建 PR 时务必选择merge合并提交而不是 squash压缩合并——必要时可能需要临时调整仓库设置才能做到。6.4 在 SDK 检出中提升 DEPS 版本并上传 CL回到 SDK 检出目录使用tools/manage_deps.dart创建一个 bump 提交和一个将发布通道移动到新遴选提交注意是遴选提交而非合并提交的 CLdart-sdk/sdk/ tools/manage_deps.dart bump third_party/pkg/pub --target6d1857c84cfb8a014aefedaf2d453214bf5ddb96然后将该 CL 改为相对于发布通道dart-sdk/sdk/ git branch --set-upstream-toorigin/beta dart-sdk/sdk/ git cl upload这个 CL 即可直接用于上文所述的 cherry-pick 流程。源码侧证tools/manage_deps.dart 的实现印证了上述流程bump命令会先检查 git 工作区是否干净、创建bump_dependency分支、通过gclient getdep -r sdk/dependency找到当前修订、再用gclient setdep -r sdk/dependencytarget更新 DEPS 中对应的依赖条目并同步依赖最后创建带git log的提交并提示创建 CL。而 DEPS 中Var(dart_root) /third_party/pkg/pub一栏正对应Var(dart_git) pub.git Var(pub_rev)即每个依赖修订号最终以revision形式固化在 DEPS 文件中。七、常见注意事项与要点速查环节关键要求适用范围仅 bug 与回归修复新功能等待下一版本目标分支origin/beta或origin/stable禁止直接落地 CL提交信息首行加[beta]/[stable]Reviewed-on改名为Cherry-pick删除Change-id/Commit-queue/Reviewed-by描述字段Issue description / What is the fix / Why cherry-pick / Risk / Issue link(s)CHANGELOGstable 必须写beta 不写无小节则新增并递增 patch 号不写日期已发布小节不可改豁免对用户不可见的基础设施变更可用Changelog-Exempt: ...评审与提交领域专家 团队负责人评审commit queue 对比上一提交防回归必要时可强制提交依赖遴选先在依赖仓库推送遴选合并进其默认分支再manage_deps.dart bump提升 SDK 依赖版本版本号联动stable cherry-pick 递增 PATCH见 tools/VERSION 注释规则掌握上述流程后无论是 SDK 自身代码的紧急修复还是third_party依赖中的关键补丁都能安全、合规地进入 beta/stable 热修复版本第一时间交付给受影响的用户。赞分享编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载相关推荐rsuite-table源码解析深入理解高性能表格组件的实现原理rsuite table源码解析深入理解高性能表格组件的实现原理 rsuite table是一个功能强大的React表格组件库专为处理大规模数据而设计。作为桌面应用富文本Flutter 构建发布渠道build/release channels全解析master、beta、stable 的选择、切换与热修复流程Flutter 构建发布渠道build/release channels全解析master、beta、stable 的选择、切换与热修复流程 Flutte跨平台移动开发前端UI组件桌面应用Realm Swift SDK 发布流程全指南master 正式版、分支预发布与热修复补丁的完整发布手册Realm Swift SDK 发布流程全指南master 正式版、分支预发布与热修复补丁的完整发布手册 导读 本文以仓库 contrib/ReleasePr数据库移动开发嵌入式数据库上一篇Vue.Draggable组件状态管理性能分析Chrome DevTools下一篇CRI-O多运行时支持终极指南如何在同一个Kubernetes集群中灵活切换不同OCI运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考