When you run shorebird patch we know what app_id you're using, but we don't yet know what release version you're trying to patch. Since Gradle and XCode can end up changing the final release-version which is built into the application (info.plist, AndroidManifiest.xml) we need to actually perform a full build to figure out what version they're going to use.
The problem is, we don't at this time know which version of flutter to use.
We could also fetch the latest release and use that flutter revision? (that might be wrong if they've checked out an older release for the same app_id that they're patching?)
Alternatively we could try looking for an fvm file?
Or we could invent a new way in shorebird.yaml or similar to encode a version number?
The customer also had some confusion about if --release-version referred to the version of Flutter. I suspect this is just general indication that our current UX here needs work. :)
https://discord.com/channels/1030243211995791380/1030243213002412164/1231014847479808010 is another example.
When you run
shorebird patch
we know what app_id you're using, but we don't yet know what release version you're trying to patch. Since Gradle and XCode can end up changing the final release-version which is built into the application (info.plist, AndroidManifiest.xml) we need to actually perform a full build to figure out what version they're going to use.The problem is, we don't at this time know which version of flutter to use.
We could also fetch the latest release and use that flutter revision? (that might be wrong if they've checked out an older release for the same app_id that they're patching?) Alternatively we could try looking for an fvm file? Or we could invent a new way in shorebird.yaml or similar to encode a version number?