Flutter 生态发布维护稳定版发布后如何更新 packages 与 core-packages 仓库【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter本文基于 Flutter 仓库中的生态维护文档完整讲解一次 Flutter 稳定版stable发布之后flutter/packages 与 flutter/core-packages 两个生态仓库需要执行的配套更新流程包括稳定版 pin、Flutter 与 Dart 的版本映射、N-1/N-2 遗留分析测试矩阵、最低 SDK 版本提升的仓库工具命令以及被阻塞 issue/PR 的清扫与优先级升级策略。读完后你可以独立完成一次完整的“稳定版发布后生态仓库同步”操作并理解每一步为何必须这样做、哪些步骤必须合并在同一个 PR 中。一、整体流程与触发时机Flutter 生态中官方包仓库flutter/packages 中的联邦插件、flutter/core-packages 中的核心包与 Flutter SDK 本身的版本是耦合的包的 CI 测试矩阵、最低 SDK 约束、发布流水线都锚定在某个 stable 版本上。因此每当 Flutter 发布一个新的稳定版这两个仓库都需要同步一次“版本水位”。文档给出的首要结论是按发布类型区分工作量Hotfix 发布补丁版不需要任何手动改动。因为 autoroller自动滚动机器人会自动更新仓库中 pin 住的 stable 版本.ci/flutter_stable.versionCI 会自然跟上。完整稳定版发布约每季度一次需要人工更新仓库即本文的核心内容。理解这个触发时机需要先了解仓库的版本支持策略flutter/packages 的总体策略是支持最新的stable与当前的master而比当前 stable 更旧版本只有极少量测试——目前只是对前两个 stable 版本N-1 与 N-2做分析analysis-only级别的测试。这一政策在 支持的 Flutter 版本策略 中有明确记载它正是后文“N-1/N-2 legacy analysis tests 必须随每次稳定版发布更新”的原因测试矩阵的水位必须随 stable 一起前移。从整体上看一次稳定版后的更新由四部分构成flutter/packages 仓库的若干配置与约束更新flutter/core-packages 仓库的对应但形态不同的更新清扫被打上p: waiting for stable update标签的 issue清扫同标签的 PR。这些步骤可以分开做但通常合并成单个 PR 最简单——原文档给出的合并 PR 示例即 flutter/packages 的一次典型“稳定版同步”提交。二、flutter/packages六项必改内容以下六项是完整稳定版发布后flutter/packages 需要逐项完成的人工更新。每一项我都附上文档给出的动机与操作细节。2.1 更新 stable pin且 autoroller 的 PR 会失败第一个要改的是仓库中 pin 住 stable 版本的文件.ci/flutter_stable.version。这里有一个容易踩坑的细节autoroller 会自动为一个新的 pin 值开 PR但该 PR 几乎必然失败。原因是 autoroller 生成的 PR 会为“自上次 stable 以来每一个 Flutter 提交”分别生成一个独立 commitcommit 数量巨大导致 CLA贡献者许可协议检查被淹没而失败。文档给出两条处理路径二者都安全直接 override 掉 CLA 检查——这是安全的因为源仓库flutter/flutter本身就强制执行 CLA或者手工新开一个 PR只更新 pin 的 hash 值。实际维护中通常选择后者一个只含 pin 更新的小 PR干净且可直接合入。2.2 更新 Flutter 与 Dart 的版本映射第二个要改的是 Flutter 各版本与对应 Dart 版本的映射表它位于仓库工具的script/tool/lib/src/common/core.dart中原文档链接到约 L70–L106 的区间。这个映射是后续所有版本换算例如由--flutter-min推出对应 Dart 最低版本的数据基础。操作要点有两条加入本次新发布的 stable 版本及其对应 Dart 版本可查阅 Flutter SDK 的 release 归档页作为对照同时补上上一个 stable 的最后一个 bugfix 版本号——因为下一步配置 N-1 测试时需要用到它。这一步是“先修数据、再改配置”的依赖起点如果映射表里没有新条目后面的工具命令和 CI 配置都无法正确引用新版本号。2.3 更新 N-1 与 N-2 遗留分析测试第三项是 CI 配置中的N-1 / N-2 legacy analysis tests位于.ci.yaml原文档链接到约 L290–L304 的区间。这两个任务分别用“前一个”和“前两个”稳定版 Flutter 对包做分析级别检查是仓库对旧版本仅有的覆盖面见 支持的 Flutter 版本策略 中“比当前 stable 更旧版本只有 analysis-only 测试”的表述以及 理解 Packages 测试 中对legacy_version_analyze等任务的说明。版本选择惯例这两个测试一般使用对应 stable 系列的最新 bugfix 版本而非 .0。这也解释了 2.2 中为何要补记“上一个 stable 的最后 bugfix 版本”。2.4 提升仓库允许的最低 Flutter 版本到 N-2第四项是把仓库级别的最低 Flutter 版本约束配置在.repo_tool_config.yaml原文档链接到第 12 行附近更新为N-2 版本。两个关键惯例值得注意取 N-2 的.0版本而不是该系列的最新 hotfix。依据是“hotfix 中不会出现破坏分析的变更”这一假设因此.0足够保守且稳定这一步理想情况下应与 2.3N-1/N-2 测试矩阵放在同一个 PR 中完成因为最低版本前移的瞬间仓库对上一个最低版本的覆盖就消失了——矩阵与约束必须原子性地一起换水位。2.5 批量更新所有包的最低 SDK 版本最低版本提升确定后需要把所有包的最低 SDK 约束同步到新水位。这一步可以借助仓库工具一行完成dart run script/tool/bin/flutter_plugin_tools.dart update-min-sdk --flutter-min3.44.0上式为原文档示例版本号以实际发布版本替换。工具入口即script/tool下的flutter_plugin_tools其命令体系在 仓库结构文档 的 Tools 一节有概述。这一步有几个配套规则是生态仓库版本策略的直接体现这类变更不做版本号 bump。仓库贡献政策 明确将“调整测试矩阵时为所有包更新最低 Dart/Flutter SDK”列为免版本变更version-exempt的典型情形。因此配套的update-release-info命令要用--versionnext即写入## NEXT段而非新版本号dart run script/tool/bin/flutter_plugin_tools.dart update-release-info \ --versionnext \ --changelogUpdates minimum supported SDK version to Flutter 3.44/Dart 3.12. \ --base-branch HEAD^ \ --run-on-changed-packages这条命令的技巧在于先让update-min-sdk单独成为一个 commit然后用--base-branch HEAD^加上--run-on-changed-packages把 CHANGELOG 更新精确限定在那个 commit 改动的包上避免波及全仓库。需要人工清理对于那些在“上一次 stable 至今”期间没有发布过版本的包它们的## NEXT段里可能已经存在一条旧的 SDK bump 记录此时要把重复的 SDK bump 行删掉防止同一条 changelog 里出现多次 SDK 提升。必须与 2.4 在同一步同一 PR完成否则 CI 会失败——因为约束文件与包内pubspec.yaml的最低版本必须一致仓库检查不允许二者漂移。2.6 更新 release action 使用的 stable最后一项是把发布工作流.github/workflows/release.yml中使用的 Flutter 版本更新为新 stable原文档链接到第 34 行附近。这保证自动发布流程版本变更 → 发布 CI 推送到 pub.dev详见 发布流程文档也在新的稳定版上进行构建与发布验证。2.7 合并为一个 PR 的建议文档明确建议上述步骤虽然可以逐个独立提交但最省事的做法是合并成单个 PR落地。这样 pin、映射、测试矩阵、最低版本、全部包的约束、发布流水线六处变更一次换水位避免中间状态导致 CI 反复红。三、flutter/core-packages相同的目标不同的 CI 形态flutter/core-packages 需要做概念上相同的变更但由于 CI 组织方式不同落点不一样。逐条对照没有单一的stablepin也没有独立的 N-1/N-2 测试任务。取而代之的是每个引用了具体 Dart 版本的 GitHub Action 都要逐个更新包括多版本 Dart 分析与测试矩阵.github/workflows/multi_version_tasks.yaml原文档链接到第 31 行附近——其中应包含 flutter/packages 中每个 Flutter 版本对应的stable、N-1、N-2 三档 Dart 版本Windows 上的 Dart 单元测试.github/workflows/windows_unit_tests.yaml第 36 行附近发布工作流.github/workflows/release.yml第 31 行附近。仓库级工具配置里设置的是最低 Dart 版本.repo_tool_config.yaml第 14 行附近而非最低 Flutter 版本。这与 flutter/packages 的.repo_tool_config.yaml设置最低 Flutter 版本形成对照。工具命令的一个已知限制仓库工具目前没有--dart-min选项。因此需要基于包含了 flutter/packages 步骤中版本映射改动的本地工具副本来运行update-min-sdk并传入同样的--flutter-min值——它会被已更新过的映射表换算成正确的 Dart 最低版本。换句话说core-packages 的版本映射更新必须先于工具命令执行完成两个仓库的变更存在顺序依赖。四、Issue 清扫p: waiting for stable update稳定版发布落地后还有一批“等人”的工作项需要处理。4.1 解除阻塞遍历所有带p: waiting for stable update标签的 issue凡是因新 stable 到位而解除阻塞的更新其状态并移除该标签表明现在可以着手处理了。4.2 废弃 API 使用类 issue 升级为 P1对于内容是“某处使用了已被废弃 API”的 issue要将其升级为 P1并二选一为它找到一个负责人或移除其所属团队的triaged-*标签同时留下评论废弃 API 的使用必须尽快移除以最小化未来对包客户端的冲击。文档解释了把这类问题定为 P1 的动机这一点值得展开大量客户端并不频繁更新自己的包尤其是传递依赖。因此距离 API 最终移除的时间点越早就发布掉修复版本将来 Flutter 升级时出现编译错误的客户端就越少。换言之废弃 API 的清理是“时间越早、生态痛感越小”的维护债务稳定版发布正是推动它的最合适时机。五、PR 清扫同样的标签同样要处理与 issue 平行还要清扫 flutter/packages 中所有带waiting for stable update标签的PR逐一检查视情况留下评论并移除/调整标签。被这些 PR 阻塞或等待的变更例如等待新 stable 的 API 才能落地的改动在新 stable 就位后大多可以重新推进不应让它们滞留。六、与发布机制的关系最后把这套更新放回生态仓库的发布机制里看会更完整flutter/packages 的包采用自动发布master 上任何包含版本更新的提交都会触发名为 “release” 的 GitHub Action把新版本发布到 pub.dev 并推送 tag该 CI 只在 post-submit 运行且要等其他 CI 全部通过后启动详见 发布流程。2.6 更新 release action 的意义就在于让这条发布链路使用新的 stable 构建。本文 2.4/2.5 的最低 SDK 提升属于免版本变更走## NEXTchangelog 段贡献政策 中版本豁免一节它们会随之后最近的版本化发布一起被“收编”进正式 changelog——这也正是 2.5 中要求清理重复 SDK bump 行的原因。注意 release CI不会自动发布flutter_plugin_tools这个工具包本身发布文档中的明确备注涉及工具自身更新时需另行处理。七、一次稳定版同步的操作清单综合上述内容可以把整个流程压缩成一份可执行的 checklistflutter/packages更新.ci/flutter_stable.version手工 PR 或 override CLA 检查。flutter/packages更新script/tool/lib/src/common/core.dart的 Flutter↔Dart 版本映射包含新 stable 与上一 stable 的最后 bugfix 版本。flutter/packages把.ci.yaml中 N-1/N-2 遗留分析测试指向前两个 stable 的最新 bugfix 版本。flutter/packages把.repo_tool_config.yaml的最低 Flutter 版本提到 N-2 的.0与第 3 步同 PR。flutter/packages运行update-min-sdk --flutter-minN-2更新所有包约束随后用update-release-info --versionnext --base-branch HEAD^ --run-on-changed-packages写 CHANGELOG并清理重复的 SDK bump 行与第 4 步同 PR。flutter/packages把.github/workflows/release.yml指到新 stable。flutter/core-packages更新multi_version_tasks.yaml矩阵含 stable/N-1/N-2 三档 Dart、windows_unit_tests.yaml、release.yml。flutter/core-packages更新.repo_tool_config.yaml的最低 Dart 版本用包含新映射的本地工具副本运行update-min-sdk --flutter-min同一值。清扫p: waiting for stable updateissue解除阻塞者去标签废弃 API 使用者升 P1 并指派负责人或留评论。清扫同标签 PR评论并按需调整标签。八、适用前提与文档边界需要说明三点前提便于读者判断本文结论的适用范围本文全部流程描述以当前 Flutter 仓库中的 Updating Packages repo for a stable release 文档为准版本命名N、N-1、N-2、测试形态analysis-only与工具选项如尚无--dart-min均按该文档现状陈述实际执行时以两个生态仓库当时的文件与工具版本为准。文档中引用的 CI 配置文件.ci.yaml、.repo_tool_config.yaml、各 workflow与工具源码位于 flutter/packages、flutter/core-packages 两个独立仓库本文仅按文档所述给出其路径与用途具体行号与内容会随那两个仓库的演进漂移。配套阅读建议版本与 CHANGELOG 规则见 贡献政策CI 任务与失败排查见 理解 Packages 测试发布与回收retract流程见 发布流程生态文档总入口为 ecosystem 索引。【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Flutter 生态发布维护：稳定版发布后如何更新 packages 与 core-packages 仓库
Flutter 生态发布维护稳定版发布后如何更新 packages 与 core-packages 仓库【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter本文基于 Flutter 仓库中的生态维护文档完整讲解一次 Flutter 稳定版stable发布之后flutter/packages 与 flutter/core-packages 两个生态仓库需要执行的配套更新流程包括稳定版 pin、Flutter 与 Dart 的版本映射、N-1/N-2 遗留分析测试矩阵、最低 SDK 版本提升的仓库工具命令以及被阻塞 issue/PR 的清扫与优先级升级策略。读完后你可以独立完成一次完整的“稳定版发布后生态仓库同步”操作并理解每一步为何必须这样做、哪些步骤必须合并在同一个 PR 中。一、整体流程与触发时机Flutter 生态中官方包仓库flutter/packages 中的联邦插件、flutter/core-packages 中的核心包与 Flutter SDK 本身的版本是耦合的包的 CI 测试矩阵、最低 SDK 约束、发布流水线都锚定在某个 stable 版本上。因此每当 Flutter 发布一个新的稳定版这两个仓库都需要同步一次“版本水位”。文档给出的首要结论是按发布类型区分工作量Hotfix 发布补丁版不需要任何手动改动。因为 autoroller自动滚动机器人会自动更新仓库中 pin 住的 stable 版本.ci/flutter_stable.versionCI 会自然跟上。完整稳定版发布约每季度一次需要人工更新仓库即本文的核心内容。理解这个触发时机需要先了解仓库的版本支持策略flutter/packages 的总体策略是支持最新的stable与当前的master而比当前 stable 更旧版本只有极少量测试——目前只是对前两个 stable 版本N-1 与 N-2做分析analysis-only级别的测试。这一政策在 支持的 Flutter 版本策略 中有明确记载它正是后文“N-1/N-2 legacy analysis tests 必须随每次稳定版发布更新”的原因测试矩阵的水位必须随 stable 一起前移。从整体上看一次稳定版后的更新由四部分构成flutter/packages 仓库的若干配置与约束更新flutter/core-packages 仓库的对应但形态不同的更新清扫被打上p: waiting for stable update标签的 issue清扫同标签的 PR。这些步骤可以分开做但通常合并成单个 PR 最简单——原文档给出的合并 PR 示例即 flutter/packages 的一次典型“稳定版同步”提交。二、flutter/packages六项必改内容以下六项是完整稳定版发布后flutter/packages 需要逐项完成的人工更新。每一项我都附上文档给出的动机与操作细节。2.1 更新 stable pin且 autoroller 的 PR 会失败第一个要改的是仓库中 pin 住 stable 版本的文件.ci/flutter_stable.version。这里有一个容易踩坑的细节autoroller 会自动为一个新的 pin 值开 PR但该 PR 几乎必然失败。原因是 autoroller 生成的 PR 会为“自上次 stable 以来每一个 Flutter 提交”分别生成一个独立 commitcommit 数量巨大导致 CLA贡献者许可协议检查被淹没而失败。文档给出两条处理路径二者都安全直接 override 掉 CLA 检查——这是安全的因为源仓库flutter/flutter本身就强制执行 CLA或者手工新开一个 PR只更新 pin 的 hash 值。实际维护中通常选择后者一个只含 pin 更新的小 PR干净且可直接合入。2.2 更新 Flutter 与 Dart 的版本映射第二个要改的是 Flutter 各版本与对应 Dart 版本的映射表它位于仓库工具的script/tool/lib/src/common/core.dart中原文档链接到约 L70–L106 的区间。这个映射是后续所有版本换算例如由--flutter-min推出对应 Dart 最低版本的数据基础。操作要点有两条加入本次新发布的 stable 版本及其对应 Dart 版本可查阅 Flutter SDK 的 release 归档页作为对照同时补上上一个 stable 的最后一个 bugfix 版本号——因为下一步配置 N-1 测试时需要用到它。这一步是“先修数据、再改配置”的依赖起点如果映射表里没有新条目后面的工具命令和 CI 配置都无法正确引用新版本号。2.3 更新 N-1 与 N-2 遗留分析测试第三项是 CI 配置中的N-1 / N-2 legacy analysis tests位于.ci.yaml原文档链接到约 L290–L304 的区间。这两个任务分别用“前一个”和“前两个”稳定版 Flutter 对包做分析级别检查是仓库对旧版本仅有的覆盖面见 支持的 Flutter 版本策略 中“比当前 stable 更旧版本只有 analysis-only 测试”的表述以及 理解 Packages 测试 中对legacy_version_analyze等任务的说明。版本选择惯例这两个测试一般使用对应 stable 系列的最新 bugfix 版本而非 .0。这也解释了 2.2 中为何要补记“上一个 stable 的最后 bugfix 版本”。2.4 提升仓库允许的最低 Flutter 版本到 N-2第四项是把仓库级别的最低 Flutter 版本约束配置在.repo_tool_config.yaml原文档链接到第 12 行附近更新为N-2 版本。两个关键惯例值得注意取 N-2 的.0版本而不是该系列的最新 hotfix。依据是“hotfix 中不会出现破坏分析的变更”这一假设因此.0足够保守且稳定这一步理想情况下应与 2.3N-1/N-2 测试矩阵放在同一个 PR 中完成因为最低版本前移的瞬间仓库对上一个最低版本的覆盖就消失了——矩阵与约束必须原子性地一起换水位。2.5 批量更新所有包的最低 SDK 版本最低版本提升确定后需要把所有包的最低 SDK 约束同步到新水位。这一步可以借助仓库工具一行完成dart run script/tool/bin/flutter_plugin_tools.dart update-min-sdk --flutter-min3.44.0上式为原文档示例版本号以实际发布版本替换。工具入口即script/tool下的flutter_plugin_tools其命令体系在 仓库结构文档 的 Tools 一节有概述。这一步有几个配套规则是生态仓库版本策略的直接体现这类变更不做版本号 bump。仓库贡献政策 明确将“调整测试矩阵时为所有包更新最低 Dart/Flutter SDK”列为免版本变更version-exempt的典型情形。因此配套的update-release-info命令要用--versionnext即写入## NEXT段而非新版本号dart run script/tool/bin/flutter_plugin_tools.dart update-release-info \ --versionnext \ --changelogUpdates minimum supported SDK version to Flutter 3.44/Dart 3.12. \ --base-branch HEAD^ \ --run-on-changed-packages这条命令的技巧在于先让update-min-sdk单独成为一个 commit然后用--base-branch HEAD^加上--run-on-changed-packages把 CHANGELOG 更新精确限定在那个 commit 改动的包上避免波及全仓库。需要人工清理对于那些在“上一次 stable 至今”期间没有发布过版本的包它们的## NEXT段里可能已经存在一条旧的 SDK bump 记录此时要把重复的 SDK bump 行删掉防止同一条 changelog 里出现多次 SDK 提升。必须与 2.4 在同一步同一 PR完成否则 CI 会失败——因为约束文件与包内pubspec.yaml的最低版本必须一致仓库检查不允许二者漂移。2.6 更新 release action 使用的 stable最后一项是把发布工作流.github/workflows/release.yml中使用的 Flutter 版本更新为新 stable原文档链接到第 34 行附近。这保证自动发布流程版本变更 → 发布 CI 推送到 pub.dev详见 发布流程文档也在新的稳定版上进行构建与发布验证。2.7 合并为一个 PR 的建议文档明确建议上述步骤虽然可以逐个独立提交但最省事的做法是合并成单个 PR落地。这样 pin、映射、测试矩阵、最低版本、全部包的约束、发布流水线六处变更一次换水位避免中间状态导致 CI 反复红。三、flutter/core-packages相同的目标不同的 CI 形态flutter/core-packages 需要做概念上相同的变更但由于 CI 组织方式不同落点不一样。逐条对照没有单一的stablepin也没有独立的 N-1/N-2 测试任务。取而代之的是每个引用了具体 Dart 版本的 GitHub Action 都要逐个更新包括多版本 Dart 分析与测试矩阵.github/workflows/multi_version_tasks.yaml原文档链接到第 31 行附近——其中应包含 flutter/packages 中每个 Flutter 版本对应的stable、N-1、N-2 三档 Dart 版本Windows 上的 Dart 单元测试.github/workflows/windows_unit_tests.yaml第 36 行附近发布工作流.github/workflows/release.yml第 31 行附近。仓库级工具配置里设置的是最低 Dart 版本.repo_tool_config.yaml第 14 行附近而非最低 Flutter 版本。这与 flutter/packages 的.repo_tool_config.yaml设置最低 Flutter 版本形成对照。工具命令的一个已知限制仓库工具目前没有--dart-min选项。因此需要基于包含了 flutter/packages 步骤中版本映射改动的本地工具副本来运行update-min-sdk并传入同样的--flutter-min值——它会被已更新过的映射表换算成正确的 Dart 最低版本。换句话说core-packages 的版本映射更新必须先于工具命令执行完成两个仓库的变更存在顺序依赖。四、Issue 清扫p: waiting for stable update稳定版发布落地后还有一批“等人”的工作项需要处理。4.1 解除阻塞遍历所有带p: waiting for stable update标签的 issue凡是因新 stable 到位而解除阻塞的更新其状态并移除该标签表明现在可以着手处理了。4.2 废弃 API 使用类 issue 升级为 P1对于内容是“某处使用了已被废弃 API”的 issue要将其升级为 P1并二选一为它找到一个负责人或移除其所属团队的triaged-*标签同时留下评论废弃 API 的使用必须尽快移除以最小化未来对包客户端的冲击。文档解释了把这类问题定为 P1 的动机这一点值得展开大量客户端并不频繁更新自己的包尤其是传递依赖。因此距离 API 最终移除的时间点越早就发布掉修复版本将来 Flutter 升级时出现编译错误的客户端就越少。换言之废弃 API 的清理是“时间越早、生态痛感越小”的维护债务稳定版发布正是推动它的最合适时机。五、PR 清扫同样的标签同样要处理与 issue 平行还要清扫 flutter/packages 中所有带waiting for stable update标签的PR逐一检查视情况留下评论并移除/调整标签。被这些 PR 阻塞或等待的变更例如等待新 stable 的 API 才能落地的改动在新 stable 就位后大多可以重新推进不应让它们滞留。六、与发布机制的关系最后把这套更新放回生态仓库的发布机制里看会更完整flutter/packages 的包采用自动发布master 上任何包含版本更新的提交都会触发名为 “release” 的 GitHub Action把新版本发布到 pub.dev 并推送 tag该 CI 只在 post-submit 运行且要等其他 CI 全部通过后启动详见 发布流程。2.6 更新 release action 的意义就在于让这条发布链路使用新的 stable 构建。本文 2.4/2.5 的最低 SDK 提升属于免版本变更走## NEXTchangelog 段贡献政策 中版本豁免一节它们会随之后最近的版本化发布一起被“收编”进正式 changelog——这也正是 2.5 中要求清理重复 SDK bump 行的原因。注意 release CI不会自动发布flutter_plugin_tools这个工具包本身发布文档中的明确备注涉及工具自身更新时需另行处理。七、一次稳定版同步的操作清单综合上述内容可以把整个流程压缩成一份可执行的 checklistflutter/packages更新.ci/flutter_stable.version手工 PR 或 override CLA 检查。flutter/packages更新script/tool/lib/src/common/core.dart的 Flutter↔Dart 版本映射包含新 stable 与上一 stable 的最后 bugfix 版本。flutter/packages把.ci.yaml中 N-1/N-2 遗留分析测试指向前两个 stable 的最新 bugfix 版本。flutter/packages把.repo_tool_config.yaml的最低 Flutter 版本提到 N-2 的.0与第 3 步同 PR。flutter/packages运行update-min-sdk --flutter-minN-2更新所有包约束随后用update-release-info --versionnext --base-branch HEAD^ --run-on-changed-packages写 CHANGELOG并清理重复的 SDK bump 行与第 4 步同 PR。flutter/packages把.github/workflows/release.yml指到新 stable。flutter/core-packages更新multi_version_tasks.yaml矩阵含 stable/N-1/N-2 三档 Dart、windows_unit_tests.yaml、release.yml。flutter/core-packages更新.repo_tool_config.yaml的最低 Dart 版本用包含新映射的本地工具副本运行update-min-sdk --flutter-min同一值。清扫p: waiting for stable updateissue解除阻塞者去标签废弃 API 使用者升 P1 并指派负责人或留评论。清扫同标签 PR评论并按需调整标签。八、适用前提与文档边界需要说明三点前提便于读者判断本文结论的适用范围本文全部流程描述以当前 Flutter 仓库中的 Updating Packages repo for a stable release 文档为准版本命名N、N-1、N-2、测试形态analysis-only与工具选项如尚无--dart-min均按该文档现状陈述实际执行时以两个生态仓库当时的文件与工具版本为准。文档中引用的 CI 配置文件.ci.yaml、.repo_tool_config.yaml、各 workflow与工具源码位于 flutter/packages、flutter/core-packages 两个独立仓库本文仅按文档所述给出其路径与用途具体行号与内容会随那两个仓库的演进漂移。配套阅读建议版本与 CHANGELOG 规则见 贡献政策CI 任务与失败排查见 理解 Packages 测试发布与回收retract流程见 发布流程生态文档总入口为 ecosystem 索引。【免费下载链接】flutterFlutter makes it easy and fast to build beautiful apps for mobile and beyond项目地址: https://gitcode.com/GitHub_Trending/flutter41/flutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考