Version of Android-manifest throws an error

[AlexanderMelchers]

Hi all,

After checking out versioning of the Android-manifest with version 0.8.5 of your task (in response to the issue #5 being resolved), I ran into the following error:

##[error]SemVer to int32: Version string invalid, 4993 is too large

4993 is our current build number. Interestingly enough, the build number is correctly mentioned in the Android-manifest's version name (which is set to "2.8.4993" for our major+minor+build), but the version code is set to something seemingly random, namely "940580866". I'm assuming the latter has to do with the error that's being thrown.

Kind regards,
Alexander.

[AlexanderMelchers]

This is on a VS2017 Hosted environment now, by the way...

[marc-mueller]

Hi Alexander,

Thanks for your feedback. The error is originated by the chosen algorithm (SemVer to int32). We currently have two algorithm implemented to convert a version (usually 3 to 4 digits) to an incrementing single number.

The SemVer to int32 algorithm uses 3 digits and therefore has 10 bits left per digits. Having 10 bits per digit limits the maximal value of a version digit to be 1024. If you are using SemVer, you shouldn't actually hit those limits since 1024 patches for a single Major/Minor version is quite much.

We have chosen this algorithm to have a quite small code version. I'm not too deep into JavaScript, but I think the number is 64bit. So we could add another algorithm which produces a higher number range. I have to check that also regarding android since there is also a maximum defined for the code version.

If you have some good ideas for additional algorithms, let us know. I know you asked also for more control and we will definitely extend the task to have allow better customizations. I could also think of having an external variable providing the code version (But we still want to guide people not to use variables like buildid to do so. Moving you code to another TFS/VSTS instance will then produce a version clash whereas an algorithm calculating a code version based on the SemVer will produce the same output on every instance.)

[AlexanderMelchers]

Hi Marc,

Thanks for your rapid response once again! I understand the limitations of the SemVer to int32 conversion, and now also better understand the core of the problem. That is, we don't use semantic versioning (major+minor+patch) for our App's full version numbering, but use rather major+minor+build+revision - of which we then display major+minor, but include the build number in the software information for us to more easily identify the exact version of the App. The third part of our version number is therefore much higher than you'd expect a patch number to be and hence, as I understand it, the crash.

What we've been using for a version code instead is our build number, which gives use nicely low numbers. We originally did base this on the BuildId, however, and following migration from TFS to VSTS I can see why you wouldn't want to use the BuildId for your version code. We are, unfortunately, now stuck on that though, and have found a way around this limitation by running a shell or PowerShell script to add an offset to our build number, following which we can change VSTS BuildNumber-variable using your task... But I understand your concern of not wanting users to have to deal with this mess by offering a nicely portable alternative.

In our case this is probably not going to work too well, though, as we don't have a patch number and have been using sequential build numbers for version codes. I'm not sure whether this would be compatible if we were to switch to SemVer now. Moreover, I can imagine we'd not be the only ones with this problem... Thus, it might be an option to ask the user what algorithm they'd like to use for version code generation (both on iOS and Android) - which could be an advanced setting. One of the options, the default, could them be the SemVer to int32 algorithm, whereas another could be the build number from the version source (thus the 3rd part, though this might need to be configurable then as well) or a variable. Most new applications would then likely just opt for the SemVer to int32 algorithm, whereas older/existing applications could use a variable, or part of the version from the version source they already specified. Hope this helps...

Best regards,
Alexander.