Flutter 兼容性政策
Flutter 如何处理破坏性变更问题。
Flutter 团队努力在“API 稳定性需求”与“为了修复错误、改善 API 易用性并以连贯方式提供新功能而演进 API 的需求”之间取得平衡。
为此，我们创建了一个测试注册表，您可以为自己的应用程序或库提供单元测试，我们会在每次变更时运行这些测试，以帮助我们跟踪可能破坏现有应用程序的变更。我们的承诺是：在未与这些测试的开发者协作之前，我们不会进行任何破坏这些测试的变更。协作流程包括：(a) 确定该变更是否具有足够的价值，以及 (b) 为代码提供修复方案，确保测试能够继续通过。
如果您希望通过参与此计划提供测试，请向 flutter/tests 代码仓库提交 PR。该仓库的 README 文件详细介绍了具体流程。
公告与迁移指南
#如果我们确实进行了破坏性变更（定义为导致一个或多个已提交的测试需要进行修改的变更），我们会在 flutter-announce 邮件列表以及我们的发行说明中发布变更公告。
我们提供了受破坏性变更影响的 代码迁移指南列表。
弃用政策
#我们有时会弃用某些 API，而不是直接将其“一刀切”地破坏。这与我们的兼容性政策无关，后者仅基于上述提到的已提交测试是否失败为准。
Flutter 团队不会按预定时间表删除已弃用的 API。如果团队决定删除某个已弃用的 API，将遵循与破坏性变更相同的程序。
Dart 及 Flutter 使用的其他库
#Dart 语言本身拥有独立的破坏性变更政策，相关公告发布在 Dart announce 上。
通常情况下，Flutter 团队目前对于其他依赖项不作任何关于破坏性变更的承诺。例如，新版本的 Flutter 可能会使用新版本的 Skia（Flutter 在某些平台上使用的图形引擎）或 Harfbuzz（Flutter 使用的字体整形引擎），这些更新可能会带来影响已贡献测试的变更。此类变更不一定会附带迁移指南。