skymap.release

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

1. 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.
2. 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"
   

3. Ask the user for an appropriate image for the splashscreen. Use the skymap.release-splashscreen skill for this.

Step 2. Bring the metadata up to date

Ask the user if they need to:

1. Update the sponsors (skymap.sponsors skill)
2. Update the contributors (skymap.contributors skill)
3. Regenerate the 'whats new' text (skymap.whatsnew skill) for the app, the fastlane update and the github changelog

Step 3. Remove unneeded text

1. The beta_user_help_text string in app/src/main/res/values/whatsnew_content.xml is 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.
2. Only if the user agreed to regenerate what's new text in Step 2.3: Delete the fastlane/metadata/android/<locale>/changelogs/default.txt file for every non en-US locale (delete the file entirely — Step 4 will regenerate them via translation).
3. Only if the user agreed to regenerate what's new text in Step 2.3: Delete the translated whatsnew_content.xml files 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/.

1. Check current coverage to see what's missing:

   tm languages
   

2. Translate all primary languages (covers both Android XML strings and fastlane changelogs):

   tm translate --all-primary
   

   To translate a single locale: tm translate de-DE To preview without calling the LLM: tm translate --all-primary --dry-run

3. After 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 fastlane
   

   Locales already translated by --all-primary will be skipped automatically.

4. 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 fastlane
   

5. Spot-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

1. Use the skymap.deploy-play-store skill to build and upload a new bundle and store metadata to the internal track. Note: the internal fastlane lane automatically increments versionCode in app/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).

1. Update ../CHANGELOG.md for this release. If the skymap.whatsnew skill 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>] <ReleaseName> - YYYY-MM-DD
   
   <img src="stardroid-v1/assets/splashscreens/<version>_<name_lowercase>_icon.png" width="80" alt="<ReleaseName>" />
   
   ### Added / Fixed / Changed
   - ...
   

   Use today's date. The heading must include the release name (confirmed in Step 1), and must be followed by a small circular icon image saved in Step 1.3. Icon filenames must include the version (<version>_<name_lowercase>_icon.png, e.g. "1.16.1:Caelus" → 1_16_1_caelus_icon.png). This ensures different sub-releases of the same name have distinct, versioned icons. Omit the image only if no source graphic was saved for this release. The CHANGELOG format follows Keep a Changelog.

2. 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 master
   

3. Tag the commit:

   git tag v<version>
   git push origin v<version>
   

4. Build the signed release APK:

   ./build.sh
   

   The signed APK will be at app/build/outputs/apk/gms/release/app-gms-release.apk.

5. 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
   

   Important: the CHANGELOG's <img> tag (if present) uses a path relative to the repo root (stardroid-v1/assets/splashscreens/...), which does not resolve inside a standalone GitHub release description. Before creating the release, rewrite that path to an absolute raw.githubusercontent.com URL pinned to the commit just pushed in step 2, so the icon keeps rendering even if the file is later renamed or moved:

   commit=$(git rev-parse HEAD)
   sed -i '' "s#stardroid-v1/assets/splashscreens/#https://raw.githubusercontent.com/sky-map-team/stardroid/${commit}/stardroid-v1/assets/splashscreens/#" /tmp/release_notes.md
   

   Run this substitution before the gh release create command above.

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:

1. Use fastlane to promote the internal release to alpha: bundle exec fastlane android promote_to_alpha
2. Use fastlane to promote the alpha to beta: bundle exec fastlane android promote_to_beta