Feature request - Error when trying to set unusable version code

[mrambow]

Hi :)

I recently had a build issue on android because of a "small" problem:
In a project, we set the versionCode like YYMMDD###. Because of a minor error, the code was changed to generate not 3, but 4 digits at the end of that versionCode. That exceeded the maximum length allowed for this value (2100000000), but gradle only gave the following error (line 10 is versionCode):

FAILURE: Build failed with an exception.

* Where:
Build file '/android/app/build.gradle' line: 10

* What went wrong:
A problem occurred evaluating project ':app'.
> Value is null

Would it be possible to generate a warning/error when trying to set a versionCode higher than allowed with trapeze?
Or should I file an issue with gradle for a better error message?

Thanks
Marc

[ZaLiTHkA]

to add my two cents' worth here...

Would it be possible to generate a warning/error when trying to set a versionCode higher than allowed with trapeze?

I feel like this falls outside the scope of things that Trapeze should be expected to cover..

while I do not know what it is in Google's ecosystem that imposes this "maximum value limitation" for the Android versionCode value, I do believe that they are highly unlikely to change anytime soon. it could very well be dependent on many other things.

so if Trapeze did implement any special handling for this particular property, then any changes to these limitations would likely require changes in Trapeze as well. potentially breaking changes, depending on how it changes on Google's side.

Or should I file an issue with gradle for a better error message?

similarly, I feel like this is also not something that Gradle should have any say in directly, as that in itself is a generic build system (and dependency manager, and and and...), whereas the value of this particular property is only relevant to the Android ecosystem (which simply uses Gradle).

Gradle is just reporting an error based on the current build configuration requirements, as defined in Android-specific workflows, where even those requirements are distributed in separate "build config" packages, imported and parsed by Gradle at build time.

---

some food for thought regarding an alternative way of handling this:

I created version bump helper script for my own hybrid mobile projects that uses Trapeze to apply version updates, with steps along the way that gather and validate information from different sources (CLI args, current project, SemVer checks, etc) and conditionally prompts the user (using @inquirer/prompts) with generated options to resolve conflicts along the way.

in this script, I simply use Date.now() as the value of my Android versionCode and iOS build fields, along with a comment that reads The greatest value Google Play allows for versionCode is 2100000000, so this will stop working for Google at Friday, July 18, 2036 1:20:00 PM.

this effectively turns my native project "build identifier" field into something that is auto-incrementing, that both Google and Apple happily accept, is far easier to read than extrapolating 10203 from 1.2.3 as recommended by the Android docs, and is much more meaningful than a simple "incrementing integer" as recommended by the CodeMagic (and probably other CI) docs. lastly, this implementation is now something I will literally not have to think about again for the next 12-odd years. (: