Flutter 兼容性策略

The Flutter team tries to balance the need for API stability with theneed to keep evolving APIs to fix bugs, improve API ergonomics,and provide new features in a coherent manner.

To this end, we have created a test registry where you can provideunit tests for your own applications or libraries that we will runon every change to help us track changes that would breakexisting applications. Our commitment is that we will not make anychanges that break these tests without working with the developers ofthose tests to (a) determine if the change is sufficiently valuable,and (b) provide fixes for the code so that the tests continue to pass.

If you would like to provide tests as part of this program, pleasesubmit a PR to the flutter/tests repository. The README.md file onthat repository describes the process in detail.

Announcements and migration guides

If we do make a breaking change (defined as a change that caused oneor more of these submitted tests to require changes), we will announcethe change on our flutter-announcemailing list as well as in our release notes.

We provide a list of guides for migrating code affected bybreaking changes.

Deprecation policy

We will, on occasion, deprecate certain APIs rather than outrightbreak them overnight. Deprecations are not considered breakingchanges, though the eventual removal of the deprecated feature couldbe (if it breaks any of the submitted tests).

Dart and other libraries used by Flutter

The Dart language itself has a separate breaking-change policy,documented on the Dart wiki.

In general, the Flutter team does not currently have any commitmentregarding breaking changes for other dependencies. For example,it’s possible that a new version of Flutter using a new version of Skia(the graphics engine used by Flutter) or Harfbuzz (the font shapingengine used by Flutter) would have changes that affect contributedtests. Such changes would not necessarily be accompanied by amigration guide.