|
| 1 | +--- |
| 2 | +allowed-tools: Bash(grep:*), Bash(git describe:*), Bash(git branch:*), Bash(git log:*), Bash(git diff:*), Bash(git status:*), Bash(git tag:*), Bash(git add:*), Bash(git commit:*), Bash(git reset:*), Bash(gh repo view:*), Bash(gh release view:*), Bash(gh run:*), Bash(gh run list:*), Bash(gh run watch:*), Bash(gh run rerun:*), Bash(gh workflow run:*), Bash(./gradlew:*), Edit, Read |
| 3 | +description: Release a new version - bump version, commit, tag, push, publish to Maven Central, create GitHub release |
| 4 | +argument-hint: "[major|minor|patch|<explicit-version>]" |
| 5 | +--- |
| 6 | + |
| 7 | +# Release |
| 8 | + |
| 9 | +## Current State |
| 10 | + |
| 11 | +- Current version: !`grep '^library' gradle/libs.versions.toml` |
| 12 | +- Latest git tag: !`git describe --tags --abbrev=0 2>/dev/null || echo "(no tags)"` |
| 13 | +- Current branch: !`git branch --show-current` |
| 14 | +- GitHub repo: !`gh repo view --json nameWithOwner -q .nameWithOwner` |
| 15 | + |
| 16 | +## Instructions |
| 17 | + |
| 18 | +Follow these steps precisely to create a new release. |
| 19 | + |
| 20 | +### Step 1: Preflight checks |
| 21 | + |
| 22 | +1. Verify we are on the `master` branch. If not, **stop** and warn the user. |
| 23 | +2. Verify the working tree is clean (`git status --porcelain`). If not, **stop** and warn the user. |
| 24 | +3. Pull latest: `git pull --ff-only`. If this fails, **stop** and warn the user. |
| 25 | + |
| 26 | +### Step 2: Determine version bump |
| 27 | + |
| 28 | +The current version uses pre-release identifiers (e.g., `1.0.0-alpha03`). Version bumping rules: |
| 29 | + |
| 30 | +If `$ARGUMENTS` is one of `major`, `minor`, or `patch`: |
| 31 | +- **patch**: increment the last numeric segment (e.g., `1.0.0-alpha03` → `1.0.0-alpha04`, or `1.2.3` → `1.2.4`) |
| 32 | +- **minor**: `X.Y.Z` → `X.Y+1.0` (drops any pre-release suffix) |
| 33 | +- **major**: `X.Y.Z` → `X+1.0.0` (drops any pre-release suffix) — always confirm with user first |
| 34 | + |
| 35 | +If `$ARGUMENTS` is an explicit version string (e.g., `1.0.0-beta01` or `1.0.0`), use it directly. |
| 36 | + |
| 37 | +Otherwise, analyze the commits since the last tag and suggest an appropriate bump. Present the proposed new version to the user and ask them to confirm using `AskUserQuestion`. |
| 38 | + |
| 39 | +### Step 3: Summarize changes |
| 40 | + |
| 41 | +List the commits since the last tag using `git log <last-tag>..HEAD --oneline`. Write concise, user-facing bullet points for each meaningful change. These will be used in the GitHub release body alongside the auto-generated changelog. |
| 42 | + |
| 43 | +### Step 4: Execute the release |
| 44 | + |
| 45 | +Do all of the following in order: |
| 46 | + |
| 47 | +1. Edit `gradle/libs.versions.toml` to update the `library` version on line 9 to the new version |
| 48 | +2. Build to verify nothing is broken: |
| 49 | + ``` |
| 50 | + ./gradlew apiDump |
| 51 | + ./gradlew :core:build |
| 52 | + ``` |
| 53 | + If the build fails, **stop** and help the user fix the issue before continuing. |
| 54 | +3. Stage and commit: |
| 55 | + ``` |
| 56 | + git add gradle/libs.versions.toml core/api/ |
| 57 | + git commit -m "release: vX.Y.Z" |
| 58 | + ``` |
| 59 | +4. Tag: `git tag vX.Y.Z` |
| 60 | +5. Push: `git push && git push --tags` |
| 61 | + |
| 62 | +### Step 5: Wait for CI |
| 63 | + |
| 64 | +After pushing, monitor the CI workflows triggered by the push: |
| 65 | + |
| 66 | +1. Wait a moment for workflows to trigger, then use `gh run list --branch master --limit 5` to find the runs |
| 67 | +2. Use `gh run watch <run-id>` on the test workflow run |
| 68 | + |
| 69 | +If all checks pass, proceed to Step 6. |
| 70 | + |
| 71 | +If any check fails: |
| 72 | +- **Flaky/random failure**: Rerun with `gh run rerun <run-id> --failed`, then wait again |
| 73 | +- **Real failure**: We need to roll back and fix the issue: |
| 74 | + 1. Delete the remote tag: `git push --delete origin vX.Y.Z` |
| 75 | + 2. Delete the local tag: `git tag -d vX.Y.Z` |
| 76 | + 3. Revert the release commit: `git reset --hard HEAD~1 && git push --force` |
| 77 | + 4. Help the user fix the issue, then re-release |
| 78 | + |
| 79 | +### Step 6: Create GitHub release |
| 80 | + |
| 81 | +Create the release on GitHub using the auto-generated changelog: |
| 82 | + |
| 83 | +``` |
| 84 | +gh release create vX.Y.Z --title "vX.Y.Z" --generate-notes |
| 85 | +``` |
| 86 | + |
| 87 | +This will: |
| 88 | +- Create a GitHub release with auto-generated PR-based changelog |
| 89 | +- Automatically trigger the `apple-binaries.yml` workflow (attaches XCFramework archives to the release) |
| 90 | + |
| 91 | +### Step 7: Trigger Maven Central publish |
| 92 | + |
| 93 | +Trigger the publish workflow manually: |
| 94 | + |
| 95 | +``` |
| 96 | +gh workflow run publish.yml |
| 97 | +``` |
| 98 | + |
| 99 | +### Step 8: Monitor post-release workflows |
| 100 | + |
| 101 | +1. Use `gh run list --limit 5` to find the publish and apple-binaries workflow runs |
| 102 | +2. Watch both with `gh run watch <run-id>` |
| 103 | +3. If the publish workflow fails, inform the user — they may need to check Maven Central / Sonatype credentials |
| 104 | +4. If apple-binaries fails, it can be re-triggered: `gh workflow run apple-binaries.yml` |
| 105 | + |
| 106 | +Once all workflows complete successfully, report: |
| 107 | +- Link to the GitHub release |
| 108 | +- Confirm Maven Central publish status |
| 109 | +- Confirm Apple XCFramework archives attached to release |
0 commit comments