name: skymap.release description: Make a new release of Sky Map and publish it to the Play Store.
This skill does all the steps involved in making a major or minor release of Sky Map. This skill might make use of other skills and it has some overlap with the skymap.deploy-play-store skill. Some steps might require input from the user.
Step 1. Bring the branding up to date
- Ask for release name (e.g. Jupiter) and version number (e.g. 1.14.0). Infer the next version number from the current versionName in
app/build.gradle, and suggest a release name by inferring the pattern from recent git tags (e.g. planets, constellations, stars) — but confirm both with the user before proceeding, since the theme may change. - Update the version name in build.gradle using fastlane, substituting the confirmed version and name:
bundle exec fastlane android bump_version name:"<version>:<ReleaseName>" # e.g. bundle exec fastlane android bump_version name:"1.14.0:Jupiter" - Ask the user for an appropriate image for the splashscreen. Use the
skymap.release-splashscreenskill for this.
Step 2. Bring the metadata up to date
Ask the user if they need to:
- Update the sponsors (
skymap.sponsorsskill) - Update the contributors (
skymap.contributorsskill) - Regenerate the 'whats new' text (
skymap.whatsnewskill) for the app, the fastlane update and the github changelog
Step 3. Remove unneeded text
- The
beta_user_help_textstring inapp/src/main/res/values/whatsnew_content.xmlis filled with instructions for beta testers during the beta period, and must be cleared to an empty string before a full release. Check if it has content; if so, set it to empty. It does not exist in other locales so no action is needed there. - Only if the user agreed to regenerate what's new text in Step 2.3: Delete the
fastlane/metadata/android/<locale>/changelogs/default.txtfile for every non en-US locale (delete the file entirely — Step 4 will regenerate them via translation). - Only if the user agreed to regenerate what's new text in Step 2.3: Delete the translated
whatsnew_content.xmlfiles in non en-US locales (i.e.app/src/main/res/values-<locale>/whatsnew_content.xml). Delete the files entirely — Step 4 will regenerate them.
If the user declined to regenerate what's new text, skip steps 3.2 and 3.3 entirely and skip Step 4.
Step 4. Translate missing text
Before running any translation commands, show the user the current content of
app/src/main/res/values/whatsnew_content.xml and fastlane/metadata/android/en-US/changelogs/default.txt
and ask: "Does this look good to translate?" Do not proceed until you receive explicit approval.
Prerequisites: tm must be installed globally (which tm). If missing, install it from the translationmanager project:
pip install -e /path/to/translationmanager
The project has a .tmconfig.toml already configured. Run all tm commands from stardroid-v1/.
Check current coverage to see what's missing:
tm languagesTranslate all primary languages (covers both Android XML strings and fastlane changelogs):
tm translate --all-primaryTo translate a single locale:
tm translate de-DETo preview without calling the LLM:tm translate --all-primary --dry-runAfter primary translation, also translate fastlane changelogs for all supported locales (not just primary ones — Play Store serves changelogs to every locale it supports):
tm translate --all --source fastlaneLocales already translated by
--all-primarywill be skipped automatically.If you only need to retranslate the what's new content and changelogs (e.g. after Step 3 deletions):
tm translate --all-primary --file whatsnew_content.xml tm translate --all --source fastlaneSpot-check a few locales for structural issues (no LLM needed):
tm validate de-DE tm validate fr-FR
Step 5. Upload to the Google Play Store
- Use the
skymap.deploy-play-storeskill to build and upload a new bundle and store metadata to the internal track. Note: theinternalfastlane lane automatically incrementsversionCodeinapp/build.gradle. Do not commit before this step — the Step 6 commit captures everything including this bump.
Step 6. Update github with a new release
After getting explicit confirmation from the user:
In all commands below, substitute <version> and <ReleaseName> with the values confirmed in Step 1 (e.g. 1.14.0 and Jupiter).
Update
../CHANGELOG.mdfor this release. If theskymap.whatsnewskill was run (Step 2.3), it will have prepended content without a version heading — add the heading now. If it was not run, add a new entry manually based on commits since the last release (git log <last-tag>..HEAD --oneline):## [<version>] - YYYY-MM-DD ### Added / Fixed / Changed - ...Use today's date. The CHANGELOG format follows Keep a Changelog.
Commit all changes from Steps 1–5 (version name, version code bump, splash, sponsors, contributors, whatsnew content, translations, CHANGELOG) in a single commit to master:
git add -A git commit -m "Prepare <version>:<ReleaseName> release" git push origin masterTag the commit:
git tag v<version> git push origin v<version>Build the signed release APK:
./build.shThe signed APK will be at
app/build/outputs/apk/gms/release/app-gms-release.apk.Extract the release notes for this version from
../CHANGELOG.md(the section between the new heading and the previous one) and upload the GitHub release:# Substitute the actual version number in the awk pattern awk '/^## \[<version>\]/{flag=1; next} /^## \[/{flag=0} flag' ../CHANGELOG.md \ | sed '/^[[:space:]]*---[[:space:]]*$/d' \ > /tmp/release_notes.md gh release create v<version> \ app/build/outputs/apk/gms/release/app-gms-release.apk \ --title "Sky Map <version>: <ReleaseName>" \ --notes-file /tmp/release_notes.md
Step 7. Progress the new release to beta
Before promoting, pause and explicitly ask the user to confirm that the internal build has been reviewed and tested. Do not proceed until you receive explicit approval.
Once approved:
- Use fastlane to promote the internal release to alpha:
bundle exec fastlane android promote_to_alpha - Use fastlane to promote the alpha to beta:
bundle exec fastlane android promote_to_beta