feat: `shorebird` should support older flutter versions

[eseidel]

Currently shorebird is tied to a specific flutter revision. Which also means that its tied to a specific Flutter engine and Dart VM version.

Dart snapshots are not stable between Dart revisions. Flutter includes Dart snapshots (inside libapp.so) in your application. So when you do a release with Flutter or Shorebird, if you wish to later patch that release with Shorebird, you have to do it from an exactly matching Dart revision (implying a matching Flutter and matching Shorebird revision).

shorebird does not need to be tightly coupled to a single flutter release. We could offer fvm-like functionality, of downloading different versions of Flutter per project.

If we did this, then it would be possible for us to release a new version of Shorebird, which depend on a new version of Flutter without worrying that users then have to take explicit action to downgrade their version of Shorebird in order to patch older apps in the wild.

Presumably if we did this we would only support a limited set of older flutter revisions, and only back to some certain point, as we do currently maintain (very small) patches on top of Flutter which we might have to also maintain on older branches of Flutter in this model.

[eseidel]

I expect we will do this, possibly soon. Right now we're prioritizing other work on the assumption that our users in production are comfortable being on limited to 3.10 for now. (Or comfortable manually checking out an older release of shorebird when needed.) When Dart does another breaking release (likely ~3 months or so from now judging from past schedules) we will need this.

Please feel welcome to 👍 if you need this sooner, or have other needs for older revisions.

[SpajicM]

Presumably if we did this we would only support a limited set of older flutter revisions, and only back to some certain point, as we do currently maintain (very small) patches.

Does this only depend on what the customer is building with, or does something on Shorebird server side also has to match?

I'd say user being able to (try to) pick any version is ideal, though download and cherry-pick script.

[eseidel]

Shorebird's servers can support a range of shorebird command line and updater versions.

The work here is to make shorebird command line interface with a range of flutter command line versions safely as well as publish Shorebird engine artifacts for a range of Flutter engine versions (which is the larger part of work). Thankfully Shorebird's changes to the Flutter engine are very small and so it should be straightforward to patch them to (even very old) Flutter versions, just will require some work on our part to build and test such.

[eseidel]

Such a system could also let us more easily track Flutter channels (including beta and master).

[eseidel]

Update:
Whenever we create a Release we save the exact hash of the Flutter version used to create such. This is to allow us to later pull that exact release when creating a patch (we don't support that yet, but that's what this bug is about).

Remaining work involves:

• Moving our builds into the cloud: feat: automate building of shorebird's engine in the cloud #804 (so that "build another version" becomes a money problem rather than a time problem).
• Set up at least basic testing of release versions in the cloud (currently most of our testing is manual).
• Verify we've correctly automated creation of branches (e.g. flutter_releases/2.10.3) based on a flutter tag + our shorebird stack of patches. We believe this is mostly working today, but need to check.
• Do the manual work to create alternative patches for points in the release history where our patch stack breaks (e.g. when Flutter moved from build.gradle to build.groovy) and teaching our "create a release branch from this patch stack + flutter version" about the existence of such alternatives.