More control over Android version string formats

[AlexanderMelchers]

Hi all,

Similar to my request in #6, I'd like to request more control over the version name and version code set in the Android-manifest. Our project uses a two-part version name consisting of a major+minor version for the version name, while reserving the build number for the version code. It would be great if this could be configured from within your task's configuration!

Looking forward to new releases with anticipation,
All the best,
Alexander.

[marc-mueller]

Hi Alexander

I understand your needs. How do you calculate/generate the two digits?

As written in another issue, we could provide external variables to deliver the code version as we do for providing the version to use for the replacements.

By build number you mean build id? If so, I wouldn't recommend to do so. The version increments on a system wide level. If you move your project to another VSTS instance, you will have some problems since the id starts from new. Additionally, you do not have any locical sequence in your build definition since all builds share the incremented build id. Why not using the patch version as it is meant and use a provided algorithm for the code version?

Best,
Marc

[AlexanderMelchers]

Hi Marc,

As described in #7, the problem likely derives from the fact that company-wide we're using a legacy version numbering system in which we version our App using major+minor+build+revision rather than SemVer. This is something I had not paid attention to when installing your task - and not something I was quite aware of before now either.

In any case, our major version number derives from major overhauls in the way the App looks or feels, it's overall structure, and is therefore a rather arbitrary number. The minor version number is somewhat more structured and increases incrementally with each new release of the App - which should normally follow a monthly cycle. The build number used to indeed by the BuildId, though following our migration to VSTS this is only true insofar as that we now add an offset to stay in line with the version numbers as were generated on TFS. We hardly work with revisions at all, though this is officially part of our versioning scheme.

We then apply these numbers as follows:

• android:versionName & CFBundleShortVersionString = major+minor
• android:versionCode & CFBundleVersion = "build number" (= BuildId + offset)

As explained in #7, we've written our own scripts to apply a fixed offset to the BuildId and are then updating the VSTS build's build number variable to match the version string we've generated based on this. This is indeed a cumbersome solution, but something we did not consider when we started out with the App (in fact, this scheme had been set up even before I was assigned to work on the App, and our Web team - who also use this versioning scheme - don't suffer from this problem because version numbering doesn't matter as much to them). If we'd like to change our versioning system now, however, this would take some consideration and effort, as our App itself references this versioning scheme internally. It would then best be something to do with the introduction of the next major version number.

Hence, we're a bit stuck, And though I've managed to create a feasible work-around to our issues with the BuildId we inherited from TFS, we still need to version our Android-manifest and PList files (as well as update the VSTS build number). It would make our build-definition significantly simpler to do so by using but a single build-task, and thence my interest in your work. By now we have a working build-definition, though, but I think it could be simplified if we could use your task for our purposes as well. But that rather depends then on whether our version numbering scheme is compatible with what you intend to support (without any hard feelings either way, of course)...

All the best,
Alexander.