How do peeps update their version code for android...

# random

[Colton Idle]

How do peeps update their version code for android apps automatically? Basically our CI creates a new release for internal testing on every PR that's merged into main (we use firebase app distribution). but if we dont bump the version code ourself then it just publishes with the same version code which is confusing.

paths forward i contemplated:
1. make everyone update version code in their PR (ew)
2. Have the merge to main also trigger a version code update (not bad, but sorta annoying because itd be a commit directly on main)
3. have the build/CI modify the versionCode, but dont commit it
4. considered setting version code to epoch timestamp, but that only gets us to July 18, 2036
5. maybe im missing something else?
can't really decide what to go with. tips?

[Stefan Oltmann]

You might find this useful: https://github.com/StefanOltmann/gradle-git-versioning-plugin

For the Android version code I just subtracted that much millis where the project started.
So it would start with a much lower number and then this gives you many years time.
It's unlikely any of my apps will be in use in 50 years and if so I'll find a new solution then.

[Colton Idle]

Hey! I know that guy!

[Stefan Oltmann]

I belive that git commit timestamps are the only reliable source for automatic versioning.

Anything someone needs to be done manually could be done wrong.
Also it's extra work every time.

Basing on Git history would mean that you could never change that or move repos.
It's unlikely that you will, but if so you have a problem.

Time however… time moves on, reliable.

[Colton Idle]

So if I understand correctly your plugin only "allows" one build per hour?

[dallas]

everywhere i've been does #2, though not to main, generally a created release-<versionName> branch which is auto-merged into main tho

[dallas]

generally a version.properties file

[Colton Idle]

i can see that approach when we're going to "prod" with a release. but every PR that gets merged into master creating a release branch seems a little execessive. nice to know what seatgeek and others have done though.

[dallas]

oh sorry on every PR… yeah for that kind of thing if you have auto-incrementing build ids (and esp. if you have a separate package identifier for those betas) then i would use the build id

[dallas]

that's what i've done

[ephemient]

in my company, the build process adds a git tag to the revision to be released. a custom plugin reads the last git tag to apply to the current revision and sets the gradle project version based on it. this avoids needing to create commits for version bumps while still keeping them visible in git

[Colton Idle]

hm. i know on android you cant install a lower version code, but i wonder if i increment the versionName with the tag and keep the code the same if that would allow our testers to install/upgrade in place

[ephemient]

there are no restrictions on versionName, only versionCode which must increment (unless forced to downgrade, e.g. adb install -d with debuggable builds)

[Colton Idle]

yeah. i know the play store makes sure your next versionCode int is incremented, but i wonder if you can install the same versionCode int. actually let me try to kick off another build and see if i can isntall in place of the old one /shruggie

[Colton Idle]

interesting. so firebase said a new upload was successful but it just points to the old one. hrmmmmm

[Colton Idle]

okay yeah. even with a different versionString and same versionCode it wont update in place (thats what I figured, but I wanted to make sure)

[Colton Idle]

what i think im going to do for the auto generated builds after each PR is NOT update the versionCode and instead just update the versionName to have a suffix of the git sha. this way it allows people to test new stuff.... just not in an in-place upgrade flow.

WHEN we get to the point where we're creating a new release (with a release branch like @dallas said) then we'll bump the version code that way.

i think i like that approach. so that the 20 versions generated in a day will be available to try in isolation, but not until we cut a release branch can we test upgrade flows, data migrations, etc.

[Colton Idle]

if the team doesnt like this then i think im just going to move to what stefan said and either use his plugin (but i think you can have only max 1 build per hour?) or maybe just come up with our own int creation system for YYYYMMDDHHMM

[Stefan Oltmann]

It's possible to change the logic to allow more than one.
It's just that I didn't want the number so high to keep it easily comparable.

[Stefan Oltmann]

I think I should make that configurable.

[Stefan Oltmann]

Regarding versioning you have a lot of options. Maybe something else like https://github.com/nanogiants/android-versioning also suits your needs.

[Stefan Oltmann]

My plugin worked good for me, because at Ashampoo we had the logic that the major version is the year and the other other numbers didn't really matter.
It felt easier to craft my own one.

But also the truth is that I wanted to make a Gradle plugin just to have that done once. 🫣
Similar to how everyone here creates a new logging lib just to have a library published once. 😉

[Colton Idle]

yeah. im thinking long term maybe going with a date is easiest. ill just try to make sure no one submits prs during daylight saving time lol

[Pavlos]

We have a solution which is based on Git tags so that on every tag which follows a specific format, it increments the build code, gets the version number and creates a new release. The code is open source so:
1. The GitHub action: https://github.com/WeatherXM/wxm-android/blob/main/.github/workflows/production-distribution.yml
2. The build.gradle.kts : https://github.com/WeatherXM/wxm-android/blob/main/app/build.gradle.kts