VersionCode should be autogenerated to ease release automation

[wmontwe]

To streamline our release automation process, it would be beneficial to implement an automatic version code generation strategy rather than relying on manual updates.

Reviewing the Firefox for Android project, I found they use a date-based system for generating a unique and sequentially increasing versionCode. Their method utilizes the format yDDDHHmm, where:

• y represents the last digit of the year minus 16 (e.g., 2017 becomes 1)
• DDD is the zero-padded day of the year (e.g., September 6th is 249)
• HH for the hour of the day (00-23)
• mm for the minute within the hour

This approach stays within the maximum allowed versionCode of 2,100,000,000, typically producing a 9-digit code, ensuring each version is unique and sequentially higher than the last.

I propose we adopt a similar, date-based calculation for our version code, incorporating the same format yDDDHHmm:

• y: The number of years since a base year, with 2024 as the starting point (e.g., 2024 is 0)
• DDD: The day of the year in 3 digits, zero-padded
• HH The hour of the day in 2 digits (00-23)
• mm The minute of the hour in 2 digits

For example:

• 2024-02-09 16:45 -> 0 | 040 | 16 | 45 -> 401_645 -> 6 digits
• 2025-10-12 09:23 -> 1 | 285 | 09 | 23 -> 12_850_923 -> 8 digits
• 2123-02-09 16:45 -> 99 | 040 | 16 | 45 -> 990_401_645 -> 9 digits

Alternatively the format ymmmmmm, with even more head room but harder to read:

• y The number of years since a base year, with 2024 as the starting point (e.g., 2024 is 0)
• mmmmmm Day of year in minutes + Hour in minutes + Minutes (6 digits)

This alternative approach would generate:

• 2024-02-09 16:45 -> 0 | 057_165 -> 57_165 -> 5 digits
• 2025-10-12 09:23 -> 1 | 409_523 -> 1_409_523 -> 7 digits
• 2123-02-09 16:45 -> 99 | 057_165 -> 99_057_165 -> 8 digits
• 3023-02-09 16:45 -> 999 | 057_165 -> 999_057_165 -> 9 digits

I welcome any feedback or suggestions on these proposed methods.

[ByteHamster]

I think this might cause problems with F-Droid releases. I think they parse gradle files manually and if it's not a constant, they can't do that.

[wmontwe]

Right, F-Droid expects a static version code. So, if we write the version code to a file and the release build is picking that up, it should be fine. I guess we also need to commit this file for reproducible builds.

[wmontwe]

We could also use prebuild to inject the desired date before building.

[cketti]

Is it really necessary to have a versionCode scheme based on the date? Can't we just have a script increment the version code for every release?

[wmontwe]

It eliminates the need to do manual versionCode changes. Otherwise any automation needs manual intervention or an self update. I'm not a fan of allowing CI workflows to commit code.

[wmontwe]

A total different approach is to derive the version code from a git tag. But that is usually more complicated.

[scollovati]

Currently in F-Droid all the metadata and release notes/changelog have disappeared: https://f-droid.org/en/packages/com.fsck.k9/

EDIT: Found the deedicated issue here https://github.com/thunderbird/thunderbird-android/issues/7709#issue-2179118986

[abdoughnut]

If you wanted, rather than using a git tag, you can simply count the number of commits as the version code. Something like git rev-list --first-parent --count origin/main here's a sample you could add in the gradle file.

val getVersionCode: () -> Int = {
    try {
        val stdout = ByteArrayOutputStream()
        exec {
            commandLine("git", "rev-list", "--first-parent", "--count", "origin/main")
            standardOutput = stdout
        }
        stdout.toString().trim().toInt()
    } catch (ignored: Exception) {
        -1
    }
}

[kewisch]

We're going to move forward on this since we need to generate a version code for daily builds. cketti Wolf and I talked about this and we're moving forward with the date based approach.

We should put the version code into a properties file so that we can easily keep the version code the same across channels, while bumping the version name according to branch on merge day.

Noting for the record that with Wolf's first approach our maximum version code is 2093662359, which would mean we are safe until 2232. If email survives that long I think we're good :-)

[kewisch]

There will not be a commit for each daily build, but we won't be doing daily builds on f-droid. Beta and Release builds will continue to increment by 1 where we do have the version bumps in commits. We could argue that for consistency we can use the same date based version code approach on beta/release, but since we already have a bump system now I think we could continue as is until we run into problems.