fix(release): give v0.4.15 its own versionCode so the release can actually ship - #180
Merged
Conversation
…ually ship The v0.4.15 release commit (f564869) bumped package.json and app.json `expo.version` but left `android/app/build.gradle` at versionCode 41 / versionName "0.4.14" and app.json `android.versionCode` at 41. Consequences, all observed on tag v0.4.15: - `npm run check:versions` fails, so the F-Droid publish (run 31820921979) died at its first step and the `release` job in build.yml never ran — no GitHub release exists for v0.4.15. That is the source the new in-app update check polls, so the mechanism this release exists to ship had nothing to find. - versionCode 41 is v0.4.14's. F-Droid and every direct-APK install key upgrades off versionCode, so even a successful publish would not have been offered to the 0.4.10/0.4.14 cohort. Play was unaffected only because the publish workflow overrides the code with run_number+100. Fix is the missing half of the release bump: versionCode 42 / versionName 0.4.15, plus the changelog files named after the code (distribution/ for the record, fastlane/ for F-Droid). check-version-parity.mjs now also requires distribution/changelogs/<code>.txt to exist and to describe the version being released, and the fastlane copy to exist. A stale versionCode is otherwise internally consistent and silent; verified it discriminates — code 41 with version 0.4.15 fails, 42 passes. Tests: npm test 320 pass. Co-Authored-By: Paperclip <noreply@paperclip.ing>
Owner
Author
dzianisv
added a commit
that referenced
this pull request
Aug 14, 2026
…nal (#181) Two things the v0.4.15 cut got wrong were things this doc told it to do. - PUBLISHING.md step 1 said not to bother hand-bumping `android.versionCode`. That is true for Play (CI overrides it with run_number+100) and false for the two channels that carry most of the install base: F-Droid and direct APK key upgrades off versionCode, so reusing the previous one means the release is never offered to anyone who already has that code. Step 1 now lists all four places to bump plus the changelog named after the code, and step 5 adds the two channel checks (GitHub release — the source the in-app update check polls — and the F-Droid index) that were previously implied to be unnecessary. - docs/playstore.md release history: v0.4.15 at production versionCode 153, the first release to reach production from a tag push alone (#177), plus the superseded 152 from the pre-#180 tag. Co-authored-by: engineer <engineer@gray-knight-m1.local> Co-authored-by: Paperclip <noreply@paperclip.ing>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Cutting v0.4.15 (f564869) bumped
package.json+app.jsonexpo.versionbut notandroid/app/build.gradle(stillversionCode 41/versionName "0.4.14") orapp.jsonandroid.versionCode(still 41). On tagv0.4.15:npm run check:versions, so nothing reachedfdroid/repo.build.yml'sreleasejob needsbuild+build-fdroid, and the same parity check fails thetestjob. The in-app update check added in feat(update): tell sideloaded installs that a newer version exists #179 polls GitHub releases/latest, so the mechanism this release exists to ship had nothing to find.run_number + 100(its production upload of0.4.15is fine).What changed
versionCode 42/versionName "0.4.15"inandroid/app/build.gradle,android.versionCode 42inapp.json.distribution/changelogs/42.txt+fastlane/metadata/android/en-US/changelogs/42.txt(F-Droid reads the fastlane copy).scripts/check-version-parity.mjsnow also requiresdistribution/changelogs/<versionCode>.txtto exist and to describe the version being released, plus the fastlane copy. A stale versionCode is otherwise internally consistent and silent — the existing checks all passed on it.Verification
npm run check:versions→Version metadata aligned: 0.4.15 (42); with the code put back to 41 it fails withdistribution/changelogs/41.txt describes "v0.4.14 …", not v0.4.15 — versionCode 41 belongs to an earlier release, so bump it. It discriminates.npm test→ 320 pass.After merge the
v0.4.15tag is moved to this commit so the F-Droid publish and the GitHub release actually run for it. AGE-111.