Android versionCode calculation conflicts with iOS versioning

[Schoonology]

I'm currently rolling our recently released Flutter application from v1.0.0+109 to v1.0.1+1. This is expected of an iOS application, as this is now the 1st build of the new version of our application. However, in gradle_utils:updateLocalProperties, Flutter uses the build number to calculate the versionCode, which is expected to monotonically increase.

One alternative is to call the new version v1.0.1+110, which would preserve the given versonCode "calculation" by Flutter, while breaking the convention on iOS, as the builds would start with 110.

Another pair of alternatives involves changing Flutter:

• Flutter could use a separate field in pubspec.yaml or similar to allow application developers to provide their own, manually created versionCode.
• Flutter could calculate the versionCode from the otherwise-SemVer-honoring version field in pubspec.yaml. This would place restrictions on, say, the number of each kind of version a team could produce (to 10^3, 10^4, or similar) to make the math work, but would provide an internally consistent set of expectations across Flutter/Dart, iOS, and Android.

[jmagman]

It would be great if we could optionally override the pubspec version in favor of various platform versions since they all have different requirements. Particularly, overloading a pubspec build number to correspond to CFBundleVersion is particularly clunky.
#41955 (comment)

[Schoonology]

I wanted to add more color to this. The "clunky" solution, referenced via commit above, has become critical for our developers to manage two applications in production and multiple in development.

I'll be clear that I don't think this is about pinning one platform's version number on the other; it's about honoring both platform's requirements while honoring the intents of the version field in pubspec.yaml; namely, that it follows semantic versioning: https://dart.dev/tools/pub/pubspec#version

I hope there's a solution to this that remains compatible with that goal, no matter what the solution is. Otherwise I'm afraid a patch will be necessary to provide a canonical "version" for each of our applications that can be deployed to each of our supported platforms. (If it helps, we release simultaneously to both platforms—it's the reason we chose Flutter, which works so well for this!)

[Schoonology]

Also, thank you so much @jmagman for the response, and for considering any solution to this issue.

[Schoonology]

@jmagman As before, thanks for your consideration of this issue.

I realize I didn't mention above that we have a prototype solution we've been using in production for the past year that may or may not be useful in clarifying the problem. If it's useful (again, this is not meant to be the Flutter team's solution), it's available here: 99956a6

[Schoonology]

This way, we can use a tool like https://github.com/ActionSprout/hori-hori to bump our versions in a semver-compliant way that is compatible across all platforms. 🎉