Skip to content

fix: derive version from git tag at release time#25

Merged
gmegidish merged 1 commit into
mainfrom
fix/version-from-git-tag
Jun 14, 2026
Merged

fix: derive version from git tag at release time#25
gmegidish merged 1 commit into
mainfrom
fix/version-from-git-tag

Conversation

@gmegidish

@gmegidish gmegidish commented Jun 14, 2026

Copy link
Copy Markdown
Member

Problem

The APK published under release tag 1.2.1 shipped versionName='1.2.0' because versionName was hardcoded in build.gradle.kts and never bumped when tagging. Consumers that compare a device's reported versionName against the release tag (e.g. mobilecli's agent install) never match, causing repeated reinstalls.

Fix

  • Derive versionName from a Gradle property (-PversionName=x.y.z) and compute versionCode from it; non-release builds fall back to 0.0.0-dev.
  • CI passes the git tag name into the build on tag pushes, so a release tagged 1.2.2 ships versionName='1.2.2'.

Verification

Built locally with -PversionName=1.2.1:

package: name='com.mobilenext.devicekit' versionCode='10201' versionName='1.2.1' ...

Summary by cubic

Derive APK versionName and versionCode from the git tag during release builds, so the published APK matches the release tag. Prevents reinstall loops in tools that compare the device versionName to the release tag.

  • Bug Fixes
    • Gradle reads -PversionName; defaults to 0.0.0-dev for non-release builds.
    • versionCode computed from versionName (e.g., 1.2.1 -> 10201), with a minimum of 1.
    • CI passes the tag name to Gradle on tag builds.

Written for commit 3ffc739. Summary will update on new commits.

Review in cubic

@coderabbitai

coderabbitai Bot commented Jun 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@gmegidish, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 55 minutes and 46 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b2c421c6-0121-419c-a992-7e323c6fcdd9

📥 Commits

Reviewing files that changed from the base of the PR and between d59919b and 3ffc739.

📒 Files selected for processing (3)
  • .github/workflows/build.yaml
  • CHANGELOG.md
  • app/build.gradle.kts
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/version-from-git-tag

Comment @coderabbitai help to get the list of available commands and usage tips.

@gmegidish gmegidish merged commit 1d46386 into main Jun 14, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant