For you android app developers. How does you vers...

# random

[Colton Idle]

For you android app developers.

How does you version and automate app deployments?

Essentially I'm facing some analysis paralysis:
1. Manually tag a release as new version 1.0.1, then the same dev presses a button to kickoff CI look for the last tag. and create a build. send it to firebase app distrubition.
or
2. have a CI job that a dev invokes, and it adds a tag itself and then creates a build to shipoff to firebase app dist.
I guess I'm getting caught up on what is the "operation" that signifies a new release of the app. and of course it would be super nice to have it automated. which is why optino 1 kinda feels "wrong" because the user has to manually tag and bump versions. but maybe thats just a fact of life.

the con of option 2 is that the CI creates a build and will also make the PR for the version bumps, but it technically happens after the release is sent.

idk. We have option 2 implemented. and its nice. but i think option 1 is actually better?

[rtsketo]

For me it's, any merge to main branch triggers the CI, the CI script passes a version to the Gradle and it produces the app with that version, uploads it to Google Play, etc. I don't see any benefit for counting the versions yourself. We still manually increase major and minor versions if needed, but build version is automated (Major.Minor.Build, some call the last one Patch).

[ephemient]

our back-end libraries and services are version bumped automatically by CI, with API diffing to control major.minor, but the Android app doesn't have any meaningful public API. instead we use a date-based major.minor, which is automatically updated every week (in time with a weekly release cycle) with the build number bumped on every CI build

[christophsturm]

@ephemient

with API diffing to control major.minor

that sounds awesome, how do you do it? is it a standard plugin?

[ephemient]

@christophsturm I don't touch that side of our codebase but I think it's custom tooling using swagger-diff and the like

[Tyler McCraw]

We manually tag a commit with a version number, then use this library with CI to run a build when a PR is created and tests are successful pointed at main branch: https://github.com/ReactiveCircus/app-versioning
This library automates the process of setting the build number and version name for us.

Version codes are set to a formula we use based on commits since the last git tag, so build numbers are always guaranteed to be unique.
Version names are set to the last git tag name. (e.g. "2.3.4")