release-engineering

name	release-engineering
description	Release engineering tasks for RakuRaku IME — version bumping, building release APKs, tagging, and creating GitHub releases. Use when the user asks to prepare a release, bump version, tag, or build for distribution.
argument-hint	task description

Release Engineering

You are performing release engineering tasks for RakuRaku IME (輕鬆輸入法).

Version Scheme

• versionName: semver-style MAJOR.MINOR.PATCH (e.g. 1.0.4).
• versionCode: monotonically increasing integer.
• Both are defined in app/build.gradle.kts under defaultConfig.

Bump manually by editing app/build.gradle.kts. No bumpPatchVersion Gradle task exists in this repo — do not invoke one.

Release Process

1. Ensure all changes are committed on main.

2. Bump version — edit app/build.gradle.kts:

   • Increment versionCode by 1.
   • Update versionName per the change's scope (patch / minor / major).

3. Update docs if needed — README.md, TODOs.md.

4. Run verification before committing:

   ./gradlew :app:lint
   ./gradlew :app:testDebugUnitTest        # if unit tests exist
   ./gradlew :app:assembleDebug
   ./gradlew :app:assembleRelease          # release build (minification per build.gradle.kts)
   

5. Create release commit — subject: Release <versionName>. This must happen before signing.

6. Tag the release — lightweight tag matching versionName (e.g. 1.0.4), no v prefix:

   git tag <versionName>
   

7. Build signed APKs from the tagged release commit. Signing requires a keystore passphrase — do not run the signed build automatically. Before prompting the user, explicitly remind them:

   ⚠️ Build the signed APKs from the <versionName> commit (git rev-parse <versionName>). The APK embeds a VCS-info block with the commit SHA; if you sign from a dirty or pre-commit working tree, F-Droid's reproducible build will produce a different checksum than the binary attached to the GitHub release, and the AllowedAPKSigningKeys match will fail downstream.

   Confirm git status is clean and git rev-parse HEAD matches the tag before asking the user to sign. The artifacts land in app/release/*.apk and app/debug/*.apk, with matching .asc signature files.

8. Push commit and tag after the user confirms (user's standing preference: push without pausing for confirmation when a release is fully prepared):

   git push origin main
   git push origin <versionName>
   

GitHub Release

Create the GitHub Release with gh once signed APKs are ready. Write a short human-readable summary; do not rely solely on --generate-notes.

gh release create <versionName> \
  --title "<versionName>" \
  --notes "$(cat <<'EOF'
<short human-readable summary>

**Full Changelog**: https://github.com/hiroshiyui/RakuRakuIME/compare/<previous-tag>...<versionName>
EOF
)" \
  app/release/org.ghostsinthelab.app.rakurakuime-<versionName>-release.apk \
  app/release/org.ghostsinthelab.app.rakurakuime-<versionName>-release.apk.asc \
  app/debug/org.ghostsinthelab.app.rakurakuime-<versionName>-debug.apk \
  app/debug/org.ghostsinthelab.app.rakurakuime-<versionName>-debug.apk.asc

Attach both release and debug APKs plus their .asc signatures (established pattern from 1.0.3 / 1.0.4).

F-Droid Metadata

Nothing to do here. The app is published on F-Droid and the fdroiddata metadata file (/home/yhh/MyProjects/fdroiddata/metadata/org.ghostsinthelab.app.rakurakuime.yml) is refreshed automatically by F-Droid's AutoUpdateMode: Version + UpdateCheckMode: Tags, picking up each new Builds: entry from the tagged release. Do not edit that file by hand, and do not reintroduce the old in-repo fdroid.yml reference copy — it was removed once F-Droid took over as the source of truth.

Fastlane Metadata

Fastlane per-locale changelogs must be refreshed for every versionCode that ships publicly:

• fastlane/metadata/android/en-US/changelogs/<versionCode>.txt
• fastlane/metadata/android/zh-TW/changelogs/<versionCode>.txt

Notes:

• Filename is <versionCode>.txt, not <versionName>.txt. So 1.0.4 (versionCode 6) lands at 6.txt.
• Keep each changelog to the diffs since the previous F-Droid-published versionCode, not since the prior internal bump — if versionCodes 2–5 were never published, the new changelog should cover everything since the last published one.
• Write both locales. The zh-TW copy should use 台式漢語 (not 繁體中文) phrasing.
• Screenshots under fastlane/metadata/android/{en-US,zh-TW}/images/phoneScreenshots/ are updated by the separate /take-and-update-screenshots skill — don't regenerate them here unless the UI changed visibly in this release.

Build Commands Reference

./gradlew :app:assembleDebug                # Debug build
./gradlew :app:assembleRelease              # Release build
./gradlew :app:lint
./gradlew :app:testDebugUnitTest            # Unit tests (if present)
./gradlew :app:connectedDebugAndroidTest    # Instrumented tests (needs device/emulator)
./gradlew :app:clean

Important Reminders

• Single remote: origin → [e-mail]:hiroshiyui/RakuRakuIME.git. No mirror.
• The release APK requires a signing config the user maintains outside version control.
• Force-push to main is never done without explicit user authorisation.
• Release sequence is always: bump → verify → commit → tag → sign from the tagged commit → push → gh release create. Fastlane changelogs land inside the bump commit (changelogs/<versionCode>.txt); F-Droid's fdroiddata entry updates automatically off the new tag.
• Reproducible-build reminder. F-Droid rebuilds the APK from the commit pinned in Builds: and compares checksums against the binary on the GitHub release. Signing from a dirty or pre-commit working tree silently breaks that match because the APK's VCS-info block embeds the HEAD SHA. Always sign AFTER the release commit+tag is in place.

Task: $ARGUMENTS