Dart SDK 中 analyzer 包发布准备（Prepare a Release）完整指南：多包同步发布工作流与版本策略

编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载analyzer包发布并不是一个孤立的动作——在 Dart SDK 仓库中它与_fe_analyzer_shared、analyzer_plugin、analyzer_testing、analysis_server_plugin等多个包存在main 分支 HEAD 级的相互依赖因此必须作为一个整体同步发布。本篇指南基于 pkg/analyzer/doc/implementation/releasing.md 及 pkg/analyzer/.agent/workflows/prepare_analyzer_release.md 定义的发布流程并结合当前仓库中五个包的pubspec.yaml与CHANGELOG.md实际内容完整讲解同步发布的背景原因、各包版本与依赖约束策略以及开启新 minor 版本开启新 major 版本准备正式发布三套可照抄执行的实操工作流。读完本文你将能独立完成 analyzer 生态包的一次完整发布准备并理解每一步背后的版本约束设计意图。为什么 analyzer 及相关包必须同步发布在 Dart SDK 仓库中analyzer包及其相关包共享同一套源码树彼此在main 分支最新提交HEAD上直接相互依赖analyzer依赖_fe_analyzer_shared如 pkg/analyzer/pubspec.yaml 中的_fe_analyzer_shared: ^108.0.0analyzer_plugin、analyzer_testing、analysis_server_plugin都依赖analyzer的私有实现代码analysis_server_plugin还同时依赖analyzer_plugin。仓库中缺乏自动化工具来检测某个包开始使用另一个包中**尚未发布unreleased**的功能既没有工具能提示analyzer之外的其他包用上了analyzer未发布的新 API也没有工具能提示analyzer开始使用_fe_analyzer_shared未发布的新功能。任何一个同时改动多个包的提交都可能悄悄引入对未发布代码的依赖即便人工跟踪这类提交也极易出错。因此发布策略的结论是必须假定在任意时刻一个包可能依赖另一个包中尚未发布的代码。为了安全地保持这些包同步它们应当同时发布released simultaneously这是整个发布策略的出发点。涉及的包及当前仓库状态如下版本号以本仓库实际内容为准包源码目录当前版本仓库 HEAD发布说明_fe_analyzer_sharedpkg/_fe_analyzer_shared108.0.0发布到 pub仅供analyzer使用每次 analyzer 发布都必须同步发布analyzerpkg/analyzer14.5.0-dev核心静态分析库发布到 pubanalyzer_pluginpkg/analyzer_plugin0.14.18-dev面向新旧 analyzer 插件开发者发布到 pubanalyzer_testingpkg/analyzer_testing0.4.3-dev面向新式 analyzer 插件开发者文档标注尚未发布not yet publishedanalysis_server_pluginpkg/analysis_server_plugin0.3.24-dev面向新式 analyzer 插件开发者发布到 pub说明以上版本号为当前仓库快照中的实际值实际执行发布时应以你 checkout 的仓库 HEAD 为准按下方工作流递增。_fe_analyzer_shared与analyzer每次同步发布且必须大版本递增_fe_analyzer_shared包虽然发布到 pub但它的唯一消费者就是analyzer包并不希望被 pub 上其他任何包直接依赖。为此发布策略做了两件事每次发布都视为破坏性发布breaking release_fe_analyzer_shared的每次新发布都进行 major 版本递增例如92.0.0 - 93.0.0。该包只使用 major 版本号不遵循常规的 minor/patch 语义。analyzer每次发布都必须同时发布_fe_analyzer_shared且analyzer依赖的是该新版本的精确或 caret版本例如_fe_analyzer_shared: ^108.0.0。文档指出由于该包只做大版本发布caret 约束如^82.0.0在技术上可行但意义不大实践中通常直接写成匹配新 major 的 caret 约束。此外该包在结构上刻意劝退直接依赖者其 pkg/_fe_analyzer_shared/lib 目录下没有任何文件或子目录除了src目录。如果用户直接import package:_fe_analyzer_shared/src/...这本身就强烈暗示其做法欠妥——因为 pub 上正常可用的包应当通过lib/下非src的公开入口导入。这一结构在当前仓库中可验证pkg/_fe_analyzer_shared/lib/下仅有src/一个目录。依赖analyzer私有代码的三个包随 analyzer 同步发布、精确版本约束analyzer_plugin、analyzer_testing、analysis_server_plugin三个包的代码都依赖analyzer包的私有实现代码private implementation code因此它们必须在analyzer每次发布时同步发布。三者的共同规则版本号管理各包按其自身 API 遵循基础语义化版本semantic versioning即可不强制与analyzer版本号一致当前仓库中它们使用0.x.y-dev形式的独立版本线。依赖约束三者对analyzer的依赖都必须是exact精确版本约束如analyzer: 14.5.0-dev、发布时如analyzer: 14.5.0而不是 caret 区间。其中analysis_server_plugin还有一个额外约束它同时依赖analyzer_plugin包且对该依赖同样必须使用exact 版本约束。以下约束在当前仓库的pubspec.yaml中均可直接验证pkg/analyzer_plugin/pubspec.yaml 中analyzer: 14.5.0-dev精确约束pkg/analyzer_testing/pubspec.yaml 中analyzer: 14.5.0-dev精确约束pkg/analysis_server_plugin/pubspec.yaml 中analyzer: 14.5.0-dev与analyzer_plugin: 0.14.18-dev均为精确约束。之所以必须用精确约束是因为这些包依赖的是analyzer的私有实现细节只有与发布时刻完全一致的analyzer版本才能保证私有 API 形状吻合放开为版本区间会在后续analyzer升级时静默引入不兼容风险。工作流一开启一个新的 minor 版本当analyzer需要从当前开发版本开启下一个 minor 版本例如10.0.0→10.1.0-dev时按以下步骤操作对应 releasing.md 中 Workflow: Start a new minor version 一节更新analyzer编辑 pkg/analyzer/pubspec.yaml将version设为下一个 minor 的dev版本例如10.0.0→10.1.0-dev更新 pkg/analyzer/CHANGELOG.md为新版本添加一个 section以Internal changes only作为占位内容。当前仓库的 pkg/analyzer/CHANGELOG.md 中即可看到## 14.5.0-dev标题下以* Internal changes only为占位符的写法。更新analyzer_plugin编辑 pkg/analyzer_plugin/pubspec.yaml将version设为下一个 patch 的dev版本将analyzer依赖改为步骤 1 得到的精确版本如analyzer: 10.1.0-dev更新 pkg/analyzer_plugin/CHANGELOG.md 为新版本添加 section。更新analyzer_testing编辑 pkg/analyzer_testing/pubspec.yaml将version设为下一个 patch 的dev版本将analyzer依赖改为步骤 1 得到的精确版本更新 pkg/analyzer_testing/CHANGELOG.md 为新版本添加 section。更新analysis_server_plugin编辑 pkg/analysis_server_plugin/pubspec.yaml将version设为下一个 patch 的dev版本将analyzer依赖改为步骤 1 得到的精确版本将analyzer_plugin依赖改为步骤 2 得到的精确版本更新 pkg/analysis_server_plugin/CHANGELOG.md 为新版本添加 section。准备提交信息commit message参考仓库历史中类似开启新 minor 版本的提交作为模板。工作流二开启一个新的 major 版本当需要开启新的 major 版本例如9.0.0→10.0.0-dev时流程与 minor 版本类似关键差异在于依赖约束的放宽方式——次要包允许依赖新的 major 版本区间而非精确版本更新analyzer编辑 pkg/analyzer/pubspec.yaml递增 major 版本例如9.0.0→10.0.0-dev更新 pkg/analyzer/CHANGELOG.md 为新版本添加 section以Internal changes only作为占位内容。更新analyzer_plugin编辑 pkg/analyzer_plugin/pubspec.yaml将version设为下一个 patch 的dev版本将analyzer依赖改为允许新 major 版本的约束例如analyzer: ^10.0.0-0即 caret 加预发布版本区间允许匹配10.0.0-0及之后的10.x.y更新 pkg/analyzer_plugin/CHANGELOG.md。更新analyzer_testing编辑 pkg/analyzer_testing/pubspec.yaml将version设为下一个 patch 的dev版本将analyzer依赖改为允许新 major 版本的约束例如analyzer: ^10.0.0-0更新 pkg/analyzer_testing/CHANGELOG.md。更新analysis_server_plugin编辑 pkg/analysis_server_plugin/pubspec.yaml将version设为下一个 patch 的dev版本将analyzer依赖改为允许新 major 版本的约束例如analyzer: ^10.0.0-0将analyzer_plugin依赖改为步骤 2 得到的精确版本——注意即使是在 major 版本开启流程中analysis_server_plugin对analyzer_plugin依然保持精确约束更新 pkg/analysis_server_plugin/CHANGELOG.md。准备提交信息参考仓库历史中类似开启新 major 版本的提交作为模板。工作流三准备正式发布Prepare a Release这是 prepare_analyzer_release.md 指向的核心工作流用于将处于-dev状态的各包正式定版、准备发布到 pub。共六个步骤更新_fe_analyzer_shared编辑 pkg/_fe_analyzer_shared/pubspec.yaml递增 major 版本例如92.0.0→93.0.0。这是唯一同时推进的包因为它每次发布都按破坏性发布处理。更新analyzer编辑 pkg/analyzer/pubspec.yaml将version设为发布版本去掉-dev后缀或按需递增例如14.5.0-dev→14.5.0将_fe_analyzer_shared依赖更新为步骤 1 得到的新版本例如_fe_analyzer_shared: ^93.0.0更新 pkg/analyzer/CHANGELOG.md为发布条目release entry设置正式版本号。更新analyzer_plugin编辑 pkg/analyzer_plugin/pubspec.yaml将version设为发布版本将analyzer依赖改为步骤 2 得到的精确版本例如analyzer: 14.5.0更新 pkg/analyzer_plugin/CHANGELOG.md 为发布条目设置版本号。更新analyzer_testing编辑 pkg/analyzer_testing/pubspec.yaml将version设为发布版本将analyzer依赖改为步骤 2 得到的精确版本更新 pkg/analyzer_testing/CHANGELOG.md 为发布条目设置版本号。更新analysis_server_plugin编辑 pkg/analysis_server_plugin/pubspec.yaml将version设为发布版本将analyzer依赖改为步骤 2 得到的精确版本将analyzer_plugin依赖改为步骤 3 得到的精确版本更新 pkg/analysis_server_plugin/CHANGELOG.md 为发布条目设置版本号。准备提交信息参考仓库历史中类似prepare release的提交作为模板。一个直观的发布版本组合示例结合上述规则与当前仓库状态一次完整的正式发布会形成如下依赖链示例数值仅用于说明关系_fe_analyzer_shared:108.0.0→109.0.0major 递增analyzer:14.5.0-dev→14.5.0依赖_fe_analyzer_shared: ^109.0.0analyzer_plugin:0.14.18-dev→0.14.18依赖analyzer: 14.5.0精确analyzer_testing:0.4.3-dev→0.4.3依赖analyzer: 14.5.0精确analysis_server_plugin:0.3.24-dev→0.3.24依赖analyzer: 14.5.0与analyzer_plugin: 0.14.18均为精确。发布策略背后的设计要点速览为什么_fe_analyzer_shared每次都是 breaking release它的消费方只有analyzer两者同仓开发、同步发布因此不需要为它维护向后兼容的 minor 语义统一 major 递增反而让依赖关系更简单、更可预测。为什么次要包用精确约束而不用 caretanalyzer_plugin、analyzer_testing、analysis_server_plugin依赖analyzer的私有实现任何analyzer内部重构都可能破坏它们精确版本把何时需要再次同步发布变成了显式、强制的事件。为什么开启新版本时反而允许 caret如^10.0.0-0在新 major 的开发期各包需要跟随analyzer的-dev迭代频繁联动caret 加预发布区间能减少开发期的摩擦而正式发布时则回落到精确约束保证 pub 上的发布产物彼此严格匹配。CHANGELOG 的占位惯例新开发版本以Internal changes only占位当前仓库 pkg/analyzer/CHANGELOG.md 中## 14.5.0-dev等条目均可见正式发布时再替换为真实的变更条目与正式版本号。配套工作流文件除 prepare release 之外pkg/analyzer/.agent/workflows/目录下还提供了两个配套的自动化工作流文件均以 releasing.md 为操作手册start_new_analyzer_minor_version.md指示读取 releasing.md 并执行 Workflow: Start a new minor versionstart_new_analyzer_major_version.md指示读取 releasing.md 并执行 Workflow: Start a new major version。三者开启 minor、开启 major、准备发布共同构成 analyzer 生态包完整的版本生命周期管理闭环开发期开启新版本线 → 迭代期维护-dev版本 → 发布期统一定版同步发布。执行任一工作流时请始终以仓库当前 HEAD 上各包的实际版本与依赖约束为准按序修改五个包的pubspec.yaml与CHANGELOG.md并保持依赖约束类型精确 / caret与工作流要求一致。赞分享编程语言编译器语言运行时标准库开发工具【免费下载链接】sdkThe Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.项目地址https://gitcode.com/gh_mirrors/sdk1/sdk点击查看免费下载相关推荐Dart SDK 外部包维护实践指南版本管理、发布流程与 Monorepo 同步Dart SDK 外部包维护实践指南版本管理、发布流程与 Monorepo 同步 本指南以 Dart SDK 仓库的 docs/External Packag编程语言编译器语言运行时标准库开发工具Tantivy 版本发布流程指南基于 cargo-release 的工作区Workspace多包发布实战Tantivy 版本发布流程指南基于 cargo release 的工作区Workspace多包发布实战 Tantivy 是一个用 Rust 编写的全文搜全文检索后端Douyin Downloader 教程从零完成抖音主页作品批量下载免费开源Douyin Downloader 教程从零完成抖音主页作品批量下载免费开源 Douyin Downloader 是一款免费开源的抖音批量下载工具支持无网页爬虫CLI上一篇Sunshine游戏串流终极指南5步打造你的免费私人云游戏平台下一篇网盘下载速度太慢这个免费开源工具让你一键获取直链告别龟速下载创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考