@a14n My understanding is that you will be primary owner of this work. We'll be doing exploratory ports of packages over the next few weeks to get ready for this. Once we're ready to go with this, my understanding is that the process will look something like the following:

The core packages that the framework depends on need to be ported.
- These ports can either be done by landing a ported copy in a branch, or possibly by publishing
  versions with the appropriate migration tool hints and migrating against that. cc @stereotype441
@a14n and possibly others will iteratively work with the migration tool to add sufficient migration hints to the framework code that the migration tool can on demand produce a correctly migrated flutter framework.
- Correctly migrated here means no static errors and all tests pass.
We may try to run internal pre-submits with the generated trial port to shake out additional issues before landing. cc @athomas @davidmorgan
We will validate performance by running the trial port against benchmarks before landing. cc @athomas @a-siva
When we see functional and performance parity and believe that we are ready to land the port:
- The main Dart repo will turn the experiment on by default and increase the minor version (probably to 2.9).
- The ported framework (as generated by the migration tool) rolls to Flutter master
- The next dev release from Flutter and/or Dart is the first release with Null Safety available to users.
- Ported versions of the core set of packages required for a small Flutter app are landed and published. cc @kevmoo @srawlins

Does this seem reasonable? Issues or concerns about this? Things that I'm missing?

Flutter framework null safety migration #40146

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions