Flutter 兼容性策略

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

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

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

公告和迁移指南

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

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

废弃政策

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

已经废弃的 API 将会在一个宽限周期后移除。以发布至稳定版本时开始至一个日历年,或是 4 个稳定版本的发布为一个宽限周期,以时间最长的为准。

当已经废弃的 API 到达了弃用期限时,我们会依照同上的步骤移除废弃的 API。

Dart 和其它被 Flutter 使用的库

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

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