Flutter 兼容性策略

Flutter 团队努力平衡对 API 稳定性的需求和对 API 持续研发以修复 bug，提升其人机工程学体验的需求。并且我们会通过一种连贯的方式来提供新特性。

为此，我们已经创建了一个测试登记。你可以在这里针对每个改动为你的应用或库提供单元测试，以帮助我们追踪对现存应用造成破坏的那些改动。我们承诺，与这些测试的开发者进行合作以确定以下两点之前，将不会有任何改动破坏这些测试。（1）决定改动是否足够有价值；（2）提供对代码的修复方案使得这些测试能够继续通过。

作为该计划的一部分，如果你想要提供一些测试方案，请向 flutter/tests repository 提交 PR。这个仓库中的 README 文件描述了具体流程。

如果我们确实发布了一项破坏性改动（定义为：会导致一个或更多已提交的测试需要变化的改动），我们将通过 flutter-announce 邮件列表公布，并且同时写在发布版说明上。

我们提供一个受破坏性改动影响的 迁移代码指南 列表。

我们将会不定期的废弃一些确定的 API，而不是直接让他们不可用。这将独立于我们的兼容性政策，只基于已提交的测试是否失败，就如同之前描述的那样。

Flutter 团队不会定期移除过时的 API。如果团队移除了废弃的 API，则会遵循与破坏性改动相同的流程。

Dart 编程语言有 自己的破坏性改动和弃用政策，并会在 Dart 编程语言通知邮件列表 里公布。

总而言之，关于其它依赖的破坏性改动，Flutter 团队目前没有做出任何承诺。例如，有可能 Flutter 的一个新版本使用了新版本的 Skia（Flutter 使用的图形引擎）或者 Harfbuzz（Flutter 使用的字体形状引擎），将会影响到已提交测试的改动。这一类的改动不一定会被写入迁移指南。

除非另有说明，本文档之所提及适用于 Flutter 的最新稳定版本，本页面最后更新时间: 2024-08-05。 查看文档源码 或者 为本页面内容提出建议。