Pin a precise version of Flutter

[gnprice]

So far, in the prototype phase, we've been able to just always use the latest Flutter version in a given channel (either beta or main). At some point we will want more control, specifying a particular version and being sure everyone gets that version even if it's not the very newest. That way everyone's seeing the same behavior, and a change happening outside our own repo can't break our tests.

In particular, if we use versions from the Flutter main branch, then that will be a constantly moving target. Using the moving target will still be OK as long as we don't frequently see anything change that breaks us, but at some point we'll want to pin the exact version to be sure of that.

Implementation notes

The pubspec.yaml file lets us specify a lower bound for the Flutter version, but not an upper bound. (The syntax permits an upper bound, but it's ignored.) In particular it doesn't permit specifying an exact version. Upstream discussions:

• [flutter_tools] pubspec.yaml environment.flutter constraint not respected by pub get flutter/flutter#95472 (comment)
• Flutter Wrapper Support. flutter/flutter#26577 (comment)
• It should be possible to pin Flutter Projects to a specific Flutter version flutter/flutter#40428
• dependencies change for flutter depending on channel/minor update? (material_color_utilities added in dev but not stable) flutter/flutter#95807 (comment)

Relatedly, while the flutter tool provides flutter upgrade as a handy way to get the latest Flutter version within any given channel (stable, beta, or main), there's no such way to get a specific version. So if Flutter did respect the pubspec.yaml file as far as complaining when the version was newer than specified, it still wouldn't provide a convenient way to actually get the specified version.

From those upstream threads, it seems like the usual solution in the Flutter community is to use one of several tools people have built to manage Flutter versions. I haven't looked into these in detail yet at all, but listing the ones I've seen mentioned:

• https://fvm.app/
• https://github.com/passsy/flutter_wrapper

So when pursuing this, we'll want to look at those and also look to see if there are other implementations to consider.

[gnprice]

This caused a bit of confusion in a recent PR:

• msglist: add scroll-to-bottom button to MessageList #223 (comment)

We also had an outright build-break a couple of months ago:

• 2f0f469 (that fix was from Parameterize the ApiConnection in getServerSettings. #103)

And there's the recurring small nuisance of:

• pubspec.lock sometimes doesn't work as a lockfile #85

So while our README says that our lack of pinning so far hasn't been a problem, that seems to no longer be true. It's not an overwhelming problem, but it is an actual problem.

---

Also, though this next part hasn't yet concretely bitten us, I'm concerned that it will get increasingly hard to run old versions of the app — say, to test whether some behavior is a regression or bisect when it changed — because there's no automated way to get a corresponding Flutter version, and no way at all to determine the exact Flutter versions that we were running at the time we were developing a given version of the app.

And unlike many kinds of problems, that isn't one where it necessarily makes sense to wait until we hit the problem before acting to solve it. That's because when you hit this problem, what you want isn't to have a solution now, but to have had a solution back when the old versions in question were developed, perhaps months earlier.

---

So I'm bumping this up in the timeline. I don't expect to have time to pick it up immediately, though.