1. What does flutter fix add over dart fix? Generally speaking I'd like to avoid adding more dart tool wrappers to the flutter tool if it is only for "branding" - its nonzero effort to maintain and we're already strapped for time.

2. Generally speaking we should only log error messages if they are actionable - if we at least know they have fixes that can be applied that could be good enough, but this information should also be surfaced through IDEs too.

( What happens if someone temporarily upgrades to master/dev/beta, applies fixes, and then wants to go back to master )

/cc @csells @devoncarew

but this information should also be surfaced through IDEs too.

The fixes do already show up as quick fixes in the IDE.

What happens if someone temporarily upgrades to master/dev/beta, applies fixes, and then wants to go back to master

We aren't currently planning on supporting any form of downgrade. Users would need to use their source code control system to revert the changes.

Seems reasonable!

Re: prompting users to run flutter/dart fix when appropriate, could this be determined by running the analyzer and seeing if there is attention needed that way?

We could add something like dart fix --dry-run --fix package:flutter or similar, which could indicate whether there were any package flutter fixes that would apply to the current codebase. That would take ~10sec to run, so not an instant result.

Do we have a way to check if there were new dart fix metadata files added? We could weaken it a bit to detecting potential fixes and directing users to dart fix

Do we have a way to check if there were new dart fix metadata files added?

The current design is to have a single file per package, but the tool could easily compare the length of the file or an MD5 hash both before and after the upgrade to determine whether there are any new fixes that users might want to run.

I actually think either of those approaches (running analyzer or checking fixes) will not be feasible on upgrade, since we don't require that command is run in the context of a flutter project.

It would have to be a per-project check of some kind

I was thinking of a message more like:

Some APIs have been modified as part of this upgrade. Running dart fix in each of your packages might help you migrate your code.