Flutter 兼容性政策

Flutter 团队致力于在保持 API 稳定性的同时，不断发展 API 以修复错误、改进 API 人机工程学，并以连贯的方式提供新功能，努力在这两者之间取得平衡。

为此，我们创建了一个测试注册表，您可以在其中为自己的应用程序或库提供单元测试，我们会在每次更改时运行这些测试，以帮助我们跟踪可能破坏现有应用程序的更改。我们承诺，在未与这些测试的开发者合作的情况下，我们不会进行任何会破坏这些测试的更改，合作内容包括 (a) 确定更改是否足够有价值，以及 (b) 为代码提供修复，以使测试继续通过。

如果您希望作为此计划的一部分提供测试，请向 flutter/tests 仓库提交 PR。该仓库的 README 文件详细描述了该过程。

如果我们确实进行了破坏性更改（定义为导致一个或多个已提交测试需要更改的更改），我们将在我们的 flutter-announce 邮件列表以及我们的发布说明中宣布此更改。

我们提供一份代码迁移指南列表，用于受破坏性更改影响的代码。

我们偶尔会弃用某些 API，而不是一夜之间完全破坏它们。这与我们的兼容性政策无关，我们的兼容性政策完全基于已提交的测试是否失败，如上所述。

Flutter 团队不会定期移除已弃用的 API。如果团队移除已弃用的 API，它将遵循与破坏性更改相同的程序。

Dart 语言本身有单独的破坏性更改政策，并在 Dart announce 上发布公告。

通常，Flutter 团队目前对其他依赖项的破坏性更改没有做出任何承诺。例如，使用新版本 Skia（Flutter 某些平台使用的图形引擎）或 Harfbuzz（Flutter 使用的字体整形引擎）的新版 Flutter 可能会有影响贡献测试的更改。此类更改不一定附带迁移指南。