// Release engineering tasks including version bumping, building release APKs, creating git tags, writing changelogs, and preparing F-Droid releases. Use when the user asks to prepare a release, bump version, tag a release, or build for distribution.
Writing/updating project documentation (README, PRIVACY-POLICY, NOTICES, changelogs) and maintaining F-Droid metadata. Use when the user asks to update docs, write changelogs, or modify F-Droid store listings.
Review code for quality, correctness, and security vulnerabilities. Use when the user asks to review code, audit for security issues, or check for bugs and anti-patterns.
Commit code changes and push via Git. Use when the user asks to commit, push, or save their work to the repository.
| name | release-engineering |
| description | Release engineering tasks including version bumping, building release APKs, creating git tags, writing changelogs, and preparing F-Droid releases. Use when the user asks to prepare a release, bump version, tag a release, or build for distribution. |
| argument-hint | task description |
You are performing release engineering tasks for Guileless Bopomofo.
MAJOR.MINOR.PATCH (e.g. 3.7.4)199)app/build.gradle.ktsBump with:
./gradlew bumpPatchVersion # increments both versionCode (+1) and patch (+1)
For minor or major bumps, edit app/build.gradle.kts manually — the task only handles patch.
The established release workflow follows this pattern:
./gradlew bumpPatchVersion or edit app/build.gradle.kts manually for minor/major bumps.app/release/ (debug builds go to app/debug/). Wait for the user to confirm the build is complete before proceeding.Release <versionName> with Signed-off-by trailer.3.7.5). Tags are NOT annotated.Release X.Y.ZX.Y.Z (just the version, no v prefix)git tag <versionName>--signoffChangelogs live at:
fastlane/metadata/android/en-US/changelogs/<versionCode>.txt
fastlane/metadata/android/zh-TW/changelogs/<versionCode>.txt
* for bullet points in en-US, ＊ (fullwidth asterisk) in zh-TW.git log --oneline <previous-tag>..HEAD
./gradlew :app:assembleDebug # Debug build
./gradlew :app:assembleRelease # Release build (minified + shrunk)
./gradlew :app:test # Unit tests
./gradlew :app:connectedAndroidTest # Instrumented tests
./gradlew :app:clean # Clean (includes libchewing build artifacts)
GPG signing requires interactive passphrase entry — do not run gpg commands automatically. Instead, prompt the user to sign the APKs manually with the commands below.
The APK filename follows the pattern org.ghostsinthelab.apps.guilelessbopomofo_v<versionName>-<buildType>.apk (configured by the archivesName setting in app/build.gradle.kts).
Provide the user with the exact commands to run:
gpg --detach-sign --armor <apk-file>
For example:
gpg --detach-sign --armor org.ghostsinthelab.apps.guilelessbopomofo_v3.7.5-release.apk
gpg --detach-sign --armor org.ghostsinthelab.apps.guilelessbopomofo_v3.7.5-debug.apk
Wait for the user to confirm signing is complete before proceeding to the GitHub Release step.
After building and GPG-signing the APKs, create a GitHub Release using gh.
Write a human-friendly release note body — do not rely solely on --generate-notes. The note should:
Structure:
<en-US changelog content>
<zh-TW changelog content>
<!-- auto-generated below -->
**Full Changelog**: https://github.com/hiroshiyui/GuilelessBopomofo/compare/<previous-tag>...<versionName>
gh release create <versionName> \
--title "<versionName>" \
--notes "$(cat <<'EOF'
<release notes body as described above>
EOF
)" \
<apk-and-asc-files...>
Upload both debug and release APKs along with their .asc signature files (4 assets total):
org.ghostsinthelab.apps.guilelessbopomofo_v<version>-debug.apkorg.ghostsinthelab.apps.guilelessbopomofo_v<version>-debug.apk.ascorg.ghostsinthelab.apps.guilelessbopomofo_v<version>-release.apkorg.ghostsinthelab.apps.guilelessbopomofo_v<version>-release.apk.ascThe release title matches the tag/versionName (e.g. 3.7.5).