ci: switch versioning to oneup CalVer (versionless git)

[ygpark80]

User description

Summary

Switch QUIK from hardcoded/manually-bumped versions to oneup CalVer (YY.MM.MICRO). presentation/build.gradle is now versionless in git; oneup computes the real version at release time from the date + prior v* git tags and writes it into the gradle file.

What changed

• presentation/build.gradle — versionless placeholders (versionCode 1, versionName '0.0.0') so the existing regex readers and archivesBaseName still parse. Comment added: version injected at release time by oneup (CalVer YY.MM.MICRO); do not bump manually.
• .github/workflows/build-and-release.yml — added a dtolnay/rust-toolchain@stable step and a Compute version (oneup CalVer) step before the existing "Capture version metadata" step. oneup installs from circlesac/oneup@feat/gradle-go-support (TODO: switch to a tagged release once feat: Android gradle + Go targets with a git-tag version source oneup#4 merges) and runs oneup version --target presentation/build.gradle --format YY.MM.MICRO. The existing read-version step then picks up the written value; the F-Droid APK naming, checksums, and the v<version> release tag (created by the existing softprops/action-gh-release step) all flow from it. Checkout already had fetch-depth: 0, so oneup's git-tag source can see prior tags. Also exposed version_name/version_code/tag_name as workflow_call outputs.
• .github/workflows/release-after-merge.yml — the fdroid-mr job now consumes the release job's version_name/version_code outputs instead of re-reading the (now versionless) gradle file. Re-running oneup there would increment past the just-released tag, so the real version is threaded through.
• .github/workflows/manual-release.yml — deprecated. The manual semver bump + release-PR flow is obsolete under oneup auto-versioning. Gutted to a thin workflow_dispatch trigger that runs the same oneup-based build-and-release.yml flow (kept the file rather than deleting it, with a deprecation comment at the top).

Notes / assumptions

• The release tag was already created by the existing gh-release step (previously v4.3.6-style, now v26.7.0-style). No new tag step was needed — this is exactly the source oneup's git-tag mode reads on the next release.
• ubuntu-latest runners generally have cargo, but the explicit rust-toolchain@stable step is added to be safe.
• No app functionality or unrelated workflows (auto-update-mms-configs, sync-upstream, validate-fastlane, build-on-pull, generate-release-notes) were touched — none of them read the version.

🤖 Generated with Claude Code

---

CodeAnt-AI Description

Move release versioning to automatic CalVer and retire manual release bumps

What Changed

• Release versions are now taken from the version computed during the main release flow, so F-Droid publishing uses the same version that was just released.
• The release workflow now passes version name and code through its outputs instead of reading them again from build.gradle.
• The manual release workflow no longer asks for a version bump or opens a release PR; it now just triggers the same automated release flow with publish and prerelease options.

Impact

✅ Fewer release version mismatches
✅ Shorter manual release process
✅ Clearer F-Droid release naming

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	da506a2	Jul 24, 2026 · 07:26	07:26

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[coderabbitai]

Warning

Review limit reached

@ygpark80, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 29 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

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.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: eac6f777-6dbc-4fb1-b8f2-f51c6e62ef04

📥 Commits

Reviewing files that changed from the base of the PR and between ca1c777 and 8f3f24f.

📒 Files selected for processing (4)

• .github/workflows/build-and-release.yml
• .github/workflows/manual-release.yml
• .github/workflows/release-after-merge.yml
• presentation/build.gradle

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/oneup-versioning

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}