About the version number storage

Hello!
I am new here, and I trying to learn how I would publush some of my applications here. I found somewhere that F-Droid requires to use a static version number at the build.gradle file. In a case of two of my apps that’s fine, they both developed for Android exclusively. However, my third application is not: it’s primarily desktop application (a game), and it has an ability to be built for Android. Initially I had the static version, however, that’s annoying because I may just forget to update version on the Android side when the actual version number is stored at the CMake build itself. In the code of build.gradle I use regular expressions to retrieve parts of the version value, and the git hash in addition, and that simplifies: I can just don’t care about the version number at all builds, and have it at the same place. I understand that it’s basically impossible to run gradle to compile version number via script. But, what about making a kind of regular expressions to allow retrieving version number from a specific file (for example, a CMake script named “version.cmake”) and parse it via regular expressions? No need to run anything also, but just parse a small regular expression to retrieve a version number.

Or, do you suggest for my case to use my version generator to just “verify” the matching of the static version number at the gradle script itself (the configure of gradle should faile if version in CMake file is different than static version in the gradle)? I do have similar thing at one of my libraries, but here is a check that CMake version and version in the public header are matching. So, if I forget to update it, the build will just fail and require me to update the public header.

Also, is there any explanation (specification) of possible fields for the yml files at fdroiddata to fill it manually?

Yes, we can parse any file to extract versionName and versionCode, but as long as they are static there.

2 Likes

In a case of my project - it’s static, yes, it’s a version.cmake file that contains separated parts of the version number, and textual suffix (it typically may have “-dev” or “-beta”, or blank for stable releases). The only one dynamical part is a git hash that gets added to the version name to simplify users to identify which actual build they use while taking it from CI. But, if is no way to insert a git hash, I can just don’t use it on F-Droid as I probably will release only stable or betas that has fixed version value/number that doesn’t require an absolute githash. The version code gets formatted by formula (verNum[0] * 1000000) + (verNum[1] * 10000) + (verNum[2] * 100) + verNum[3] from this “version.cmake” file (i.e. from version 1.3.6.1 will be 1030601). Will be also possible to make a formula in the parser to make this?

Also, what about the applicationIdSuffix and versionNameSuffix? Can I fill it with something unique for F-Droid? Knowing the fact, F-Droid does own building and own signing of builds, I want to allow F-Droid builds to don’t conflict with manually installed builds (mostly devel builds that testers and ordinary users do install manually taking from my CI build cache). I do already use the applicationIdSuffix = ".debug" when building local debug builds, they don’t conflict to builds are built by CI and released stable builds, and both versions isntalled as separated applications.

hah lol, no, that’s not static if you “generate it dynamically with a function”, static means 1.3.7.0

The version code gets formatted by formula

So not static either

you can…

Then, seems, I will need to store a duplicated copy of version value (as a static value), AND, my dynamic code will be used to VERIFY the matching (just a helper to let me DON’T forget update the second copy of version once I update the main version.cmake). And that should work. Right?

And, can I put a dummy field at the version.cmake file, but in a form of a static version value exclusively for F-Droid, making a kind of:

# Values for F-Droid to parse
set(THEXTECH_VERSION_STRING_STATIC "1.3.7.0-dev")
set(THEXTECH_VERSION_CODE_STATIC "1030700")

And then the reminder to keep this in sync with main values from above:

# A reminder that will compare dynamically computed values with a static value, and will fail a configure if mismatch:
if(NOT "${THEXTECH_VERSION_STRING_STATIC}" STREQUAL "${THEXTECH_VERSION_STRING}")
    message(FATAL_ERROR "Second version name value is not matching to the primary")
endif()

math(EXPR THEXTECH_VERSION_CODE_VERIFY "1000000 * ${THEXTECH_VERSION_1} + 10000 * ${THEXTECH_VERSION_2} + 100 * ${THEXTECH_VERSION_3} + ${THEXTECH_VERSION_4}")

if(NOT "${THEXTECH_VERSION_CODE_STATIC}" STREQUAL "${THEXTECH_VERSION_CODE_VERIFY}")
    message(FATAL_ERROR "Android version code doesn't not matching to the primary version code")
endif()

Looks good, yes

So the F-Droid versionName would be 1.3.7.0-dev, yes?

Something like, but more 1.3.7-dev: Leading zeroes gets cut down, and fourth number exists when minor patches had been released.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.