chore(android): bump app versionName to 0.1.1 - #4309
Merged
Conversation
## Related issue
N/A — chore, no issue required.
## Summary
- Bumps the Android shell's `versionName` from `0.1.0` to `0.1.1`.
- `versionCode` is intentionally untouched: it is supplied per release by CI
(`android-bundle.yml` passes `-PversionCode=<input>`, documented as "must be
higher than the last uploaded to Play; starts at 3"). The `?: 2` in
`build.gradle.kts` is only a local-build fallback, so changing it would have
no effect on what ships to Play.
## Test Plan
- `./gradlew :app:processDebugMainManifest` and inspected the merged manifest:
```
app/build/intermediates/merged_manifest/debug/processDebugMainManifest/AndroidManifest.xml
android:versionCode="2"
android:versionName="0.1.1"
```
- `pre-commit run --files web/android/app/build.gradle.kts` — passes.
## Demo
N/A — no visual change.
## Type of change
- [ ] Bug fix
- [ ] Feature
- [ ] UI / frontend change
- [x] Refactor / chore
- [ ] Docs
- [ ] Test / CI
- [ ] Breaking change
## Test coverage
- [ ] Unit tests added / updated
- [ ] Integration tests added / updated
- [ ] E2E tests added / updated
- [x] Manual verification completed
- [ ] Existing tests cover this change
- [x] Not applicable
## Coverage notes
A version-string constant has no behaviour to unit test. Verified by building
the merged manifest and confirming `android:versionName="0.1.1"` is what the
build actually emits, rather than only reading back the source line.
Signed-off-by: Zeyi (Rice) Fan <zeyi.f@databricks.com>
Contributor
|
🏷️ Doc impact: Only bumps the Android app versionName from 0.1.0 to 0.1.1, an internal version metadata change with no user-facing surface or integration affected. Auto-classified on merge. Set the label manually before merging to override. · run |
13 tasks
fanzeyi
added a commit
that referenced
this pull request
Aug 7, 2026
## Related issue N/A ## Summary - Bumps the iOS app's marketing version (`CFBundleShortVersionString`) from `0.1.0` to `0.1.1` ahead of cutting a TestFlight build, so the release is not published under the same user-facing version as the previous one. - Only the **Omnigent** app target's Debug and Release configurations change, as `web/ios/RELEASE.md` prescribes. The `.tests` / `.uitests` bundle versions are left at `0.1.0`; they are never shipped, and Android's equivalent bump (#4309) likewise touched only the app's version. - The build number is deliberately untouched: it is computed per upload as `latest_testflight_build_number + 1` and injected by fastlane at archive time, so it must not be bumped by hand. ## Test Plan - `xcodebuild build -project Omnigent.xcodeproj -scheme Omnigent -destination 'platform=iOS Simulator,name=iPhone 17,OS=26.5'` succeeds, and the built app's `Info.plist` reports the new version: `plutil -extract CFBundleShortVersionString raw .../Omnigent.app/Info.plist` → `0.1.1`. - `plutil -lint web/ios/Omnigent.xcodeproj/project.pbxproj` passes, confirming the hand-edited project file is still well-formed. - Verified the two changed entries belong to the `ai.omnigent.ios` target (Debug and Release) and that no other target's version moved. ## Demo N/A — no user-visible interface change; only the reported version string. ## Type of change - [ ] Bug fix - [ ] Feature - [ ] UI / frontend change - [x] Refactor / chore - [ ] Docs - [ ] Test / CI - [ ] Breaking change ## Test coverage - [ ] Unit tests added / updated - [ ] Integration tests added / updated - [ ] E2E tests added / updated - [x] Manual verification completed - [x] Existing tests cover this change - [ ] Not applicable ## Coverage notes A version string has no behaviour to unit test. Verified by building the app and reading `CFBundleShortVersionString` back out of the built `Info.plist`, plus a `plutil -lint` on the edited project file to catch a malformed hand edit. The existing iOS suites continue to cover app behaviour. Signed-off-by: Zeyi (Rice) Fan <zeyi.f@databricks.com>
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.
Related issue
N/A — chore, no issue required.
Summary
versionNamefrom0.1.0to0.1.1.versionCodeis intentionally untouched: it is supplied per release by CI(
android-bundle.ymlpasses-PversionCode=<input>, documented as "must behigher than the last uploaded to Play; starts at 3"). The
?: 2inbuild.gradle.ktsis only a local-build fallback, so changing it would haveno effect on what ships to Play.
Test Plan
./gradlew :app:processDebugMainManifestand inspected the merged manifest:pre-commit run --files web/android/app/build.gradle.kts— passes.Demo
N/A — no visual change.
Type of change
Test coverage
Coverage notes
A version-string constant has no behaviour to unit test. Verified by building
the merged manifest and confirming
android:versionName="0.1.1"is what thebuild actually emits, rather than only reading back the source line.