New breaking change policy and invitation to contribute tests

[Ian Hickson]

tl;dr: contribute your tests if you don't want to be broken!

Hello everyone,

In the past, we have been posting requests for feedback to this mailing list when we intend to make a change that we suspect is quite likely to break people using Flutter. This has relied on a judgement call about what is a breaking change and what is not, which has led to large inconsistencies in what we consider breaking across the team.

We are therefore changing to a new process.

First, we are inviting everyone to submit their tests to our new flutter/tests repository: https://github.com/flutter/tests

If you have an open-source application, plugin, or package using Flutter, and you have automated tests, you can contribute them to the repository above and we will run these tests every time we make a change to Flutter, however minor. (Google is contributing the resources for us to run these tests, there is no cost to you.)

If you have written proprietary software using Flutter and have a significant number of tests, we are interested in working with you to run your tests as well. For example, we will be running Google's large set of tests for Stadia, AdWords, Blogger, and other Flutter-based Google apps on every commit as part of this process.

Second, going forward, we will only consider changes that break a contributed test as being breaking changes. When we do find that we want to break a test, we will work with you to migrate your applications. We will also publish more detailed information for these breaking changes than we have in the past, including, for example, migration guides.

For more details on the policy we will be following, see our wiki:

https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes

For more details about how to contribute your tests, see this document:

https://github.com/flutter/tests/blob/master/README.md

Thanks,

--

Ian Hickson

[Pascal Welsch]

That's great news!

Is the focus of the tests repository to prevent breaking changes of the dart API only?

I was thinking about tooling around Flutter, relying on things like:

- certain paths and executables within the Flutter SDK

- calling flutter_tool and eventually parsing stdout

I personally see those as public APIs, too. If anything changes, things may break.

What about the Android and iOS APIs? FlutterView on Android is definitely a public API but I don't see how iOS or Android tests can be executed.

- Pascal