bump-version-dev

name

bump-version-dev

description

Build a release-shaped sim-use binary and install it locally for testing. Use when the user runs `/bump-version-dev` or asks to "build a dev release", "test the release build locally", "install a release build for testing", or "prepare a release candidate without publishing". Builds APK + CLI, stages, ad-hoc signs, and repoints the PATH binary. Does NOT commit, tag, push, create releases, or update homebrew. After local validation, run `/release` to ship for real.

This skill builds and locally installs a release-shaped sim-use binary so the user can validate it before publishing. It delegates the heavy lifting to scripts/dev-install.sh and handles version determination + user confirmation.

Run from the sim-use repo root (git rev-parse --show-toplevel).

Restore flow

If the user passes restore as an argument (e.g. /bump-version-dev restore), skip everything and run:

scripts/dev-install.sh --restore

Report success or failure and stop.

Step 1: Pre-flight

Run these checks. Abort with a clear error if any fails.

1. Current directory is the sim-use repo root.
2. build_products/Frameworks/ exists. If missing, tell the user to run scripts/build.sh dev (~30 min). Do NOT run it automatically.
3. Android bridge toolchain: scripts/build-bridge.sh --check succeeds. If not, surface the missing tool.

Unlike /release, this skill does NOT require:

• Clean working tree (local modifications are fine — this is a dev build)
• GitHub auth
• Homebrew tap clone
• Codesign identity or notary profile

Step 2: Determine the next version

1. Find the latest sim-use tag: git tag --list 'v*' --sort=-v:refname | head -1.
2. If a prior tag exists, read commits since it: git log <last-tag>..HEAD --pretty=format:'%h %s'.
3. Pick bump type from conventional commit prefixes:
   • feat!: / BREAKING CHANGE → major
   • feat: → minor
   • Only fix: / chore: / docs: / refactor: / test: → patch
4. Compute the next version.

If the user specified a version (e.g. /bump-version-dev 0.9.1), use that verbatim instead of auto-bumping.

Step 3: Confirm with the user

Show:

• The current tag and the target version.
• The commit list since the last tag (one line each).
• What will happen: "Build APK + CLI as vX.Y.Z, stage, ad-hoc sign, and replace the PATH binary."

Ask: "Build and install vX.Y.Z locally?" Wait for explicit yes/no/version override.

Step 4: Run the dev-install script

scripts/dev-install.sh --version X.Y.Z

This script handles:

1. Rebuilding the Android bridge APK (scripts/build-bridge.sh)
2. Building the universal CLI with SIM_USE_VERSION=X.Y.Z (scripts/build.sh executable)
3. Staging the payload (scripts/release-artifacts.sh stage-build-output + verify-stage)
4. Ad-hoc codesigning the staged payload
5. Backing up the current PATH binary target
6. Symlinking the PATH binary to the staged build
7. Verifying sim-use --version

The script typically takes 2-5 minutes. Stream the output so the user sees progress. If the script fails, diagnose:

• Bridge build failed → JDK/SDK issue, see CLAUDE.md Android pitfalls
• verify-stage failed → missing resource bundle, re-check build output
• Codesign failed → unlikely for ad-hoc; check macOS version
• Symlink failed → permission issue on the install path

Step 5: Report

After the script succeeds, report:

• The installed version (sim-use --version)
• The symlink target
• Reminder: test the build, then run /release to ship for real
• Reminder: run scripts/dev-install.sh --restore (or /bump-version-dev restore) to go back

Things to NOT do

• Don't modify CHANGELOG.md, bridge/app/build.gradle.kts, or any tracked file.
• Don't commit, tag, or push anything.
• Don't run --build-frameworks — that's a slow path requiring explicit user opt-in.
• Don't codesign with Developer ID — ad-hoc is sufficient for local testing.
• Don't create tarballs, formulas, or releases.
• Don't attempt notarization.