Skip to content

Commit d47ed33

Browse files
DIYgodDIYgod
authored
Merge pull request #4859 from RSSNext/release/mobile/0.3.0
release(mobile): Release v0.3.0
2 parents 5226bd6 + 8e0a7e8 commit d47ed33

File tree

735 files changed

+36040
-21037
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

735 files changed

+36040
-21037
lines changed

‎.claude/skills/desktop-release/SKILL.md‎

Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
---
2+
name: desktop-release
3+
description: Perform a regular desktop release from the dev branch. Gathers commits since last release, updates changelog, evaluates mainHash changes, bumps version, and creates release PR.
4+
disable-model-invocation: true
5+
allowed-tools: Bash, Read, Write, Edit, Glob, Grep
6+
---
7+
8+
# Desktop Regular Release
9+
10+
Perform a regular desktop release. This skill handles the full release workflow from the `dev` branch.
11+
12+
## Pre-flight checks
13+
14+
1. Confirm the current branch is `dev`. If not, abort with a warning.
15+
2. Run `git pull --rebase` in the repo root to ensure the local branch is up to date.
16+
3. Read `apps/desktop/package.json` to get the current `version` and `mainHash`.
17+
18+
## Step 1: Gather changes since last release
19+
20+
1. Find the last release tag:
21+
```bash
22+
git tag --sort=-creatordate | grep '^desktop/v' | head -1
23+
```
24+
2. Get all commits since that tag on the current branch:
25+
```bash
26+
git log <last-tag>..HEAD --oneline --no-merges
27+
```
28+
3. Categorize commits into:
29+
- **Shiny new things** (feat: commits, new features)
30+
- **Improvements** (refactor:, perf:, chore: improvements, dependency updates)
31+
- **No longer broken** (fix: commits, bug fixes)
32+
- **Thanks** (identify external contributor GitHub usernames from commits)
33+
34+
## Step 2: Update changelog
35+
36+
1. Read `apps/desktop/changelog/next.md`.
37+
2. Present the categorized changes to the user and draft the changelog content.
38+
3. Wait for user confirmation or edits before writing.
39+
4. Write the final content to `apps/desktop/changelog/next.md`, following the template format:
40+
41+
```markdown
42+
# What's new in vNEXT_VERSION
43+
44+
## Shiny new things
45+
46+
- description of new feature
47+
48+
## Improvements
49+
50+
- description of improvement
51+
52+
## No longer broken
53+
54+
- description of fix
55+
56+
## Thanks
57+
58+
Special thanks to volunteer contributors @username for their valuable contributions
59+
```
60+
61+
5. Keep `NEXT_VERSION` as the placeholder - it will be replaced by `apply-changelog.ts` during bump.
62+
63+
## Step 3: Evaluate mainHash
64+
65+
This is critical for determining whether users need a full app update or can use the lightweight renderer hot update.
66+
67+
1. Check what files changed in `apps/desktop/layer/main/` since the last release tag:
68+
```bash
69+
git diff <last-tag>..HEAD --name-only -- apps/desktop/layer/main/
70+
```
71+
2. Also check changes to `apps/desktop/package.json` fields other than version/mainHash (since package.json is included in the hash calculation):
72+
```bash
73+
git diff <last-tag>..HEAD -- apps/desktop/package.json
74+
```
75+
76+
**Decision logic:**
77+
78+
- If there are **NO changes** in `layer/main/` and no meaningful `package.json` changes (only version/mainHash/changelog-related), then mainHash should NOT be updated. Users will get a fast renderer-only hot update.
79+
- If there are **trivial changes** in `layer/main/` (typo fixes, comment changes, logging tweaks) that don't affect runtime behavior, recommend NOT updating mainHash. Present the changes to the user and ask for confirmation.
80+
- If there are **meaningful changes** in `layer/main/` (new features, bug fixes, dependency changes, API changes), mainHash MUST be updated. Users will need a full app update.
81+
82+
Present your analysis to the user with:
83+
84+
- List of changed files in `layer/main/`
85+
- A summary of what changed
86+
- Your recommendation (update or skip mainHash)
87+
- Ask for explicit confirmation
88+
89+
## Step 4: Save old mainHash and execute bump
90+
91+
1. Save the current mainHash from `apps/desktop/package.json` for later comparison.
92+
2. Change directory to `apps/desktop/` and run the bump:
93+
```bash
94+
cd apps/desktop && pnpm bump
95+
```
96+
3. This command will:
97+
- Pull latest changes
98+
- Apply changelog (rename next.md to {version}.md, create new next.md)
99+
- Recalculate mainHash and write to package.json
100+
- Format package.json
101+
- Bump minor version
102+
- Commit with message `release(desktop): release v{NEW_VERSION}`
103+
- Create branch `release/desktop/{NEW_VERSION}`
104+
- Push branch and create PR to `main`
105+
106+
## Step 5: Restore mainHash if skipping update
107+
108+
If Step 3 decided mainHash should NOT be updated, restore the old value now. The bump has already committed, pushed, and created the PR on a new release branch, so we amend the commit and force push. This is safe because the release branch was just created.
109+
110+
1. Change back to the repo root first (Step 4 left the working directory at `apps/desktop/`):
111+
```bash
112+
cd ../..
113+
```
114+
2. Ensure you are on the `release/desktop/{NEW_VERSION}` branch (bump should have switched to it).
115+
3. Replace the recalculated mainHash with the saved old value in `apps/desktop/package.json`.
116+
4. Stage and amend the release commit:
117+
```bash
118+
git add apps/desktop/package.json && git commit --amend --no-edit
119+
```
120+
5. Force push the release branch:
121+
```bash
122+
git push --force origin release/desktop/{NEW_VERSION}
123+
```
124+
125+
If Step 3 decided mainHash SHOULD be updated, skip this step entirely — the bump already wrote the correct new value.
126+
127+
## Step 6: Verify
128+
129+
1. Confirm the PR was created successfully by checking the output.
130+
2. Report the new version number and PR URL to the user.
131+
3. Summarize:
132+
- New version: v{NEW_VERSION}
133+
- mainHash updated: yes/no (and why)
134+
- Changelog highlights
135+
- PR URL
136+
137+
## Reference
138+
139+
- Bump config: `apps/desktop/bump.config.ts`
140+
- Changelog dir: `apps/desktop/changelog/`
141+
- Changelog template: `apps/desktop/changelog/next.template.md`
142+
- mainHash generator: `apps/desktop/plugins/vite/generate-main-hash.ts`
143+
- Hot updater logic: `apps/desktop/layer/main/src/updater/hot-updater.ts`
144+
- CI build workflow: `.github/workflows/build-desktop.yml`
145+
- Tag workflow: `.github/workflows/tag.yml`

‎.claude/skills/installing-mobile-preview-builds/SKILL.md‎

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
---
2+
name: installing-mobile-preview-builds
3+
description: Builds and installs the iOS preview build for apps/mobile using EAS local build and devicectl. Use when the user asks to install a preview/internal iOS build on a connected iPhone for production-like testing.
4+
disable-model-invocation: true
5+
allowed-tools: Bash, Read, Glob, Grep
6+
argument-hint: "[device-udid-or-name(optional)]"
7+
---
8+
9+
# Install Mobile Preview Build (iOS)
10+
11+
Use this skill to create a fresh local `preview` iOS build and install it on a connected iPhone.
12+
13+
## Inputs
14+
15+
- Optional `$ARGUMENTS`: device identifier (UDID or exact device name).
16+
- If no argument is provided, auto-select the first paired iPhone from `xcrun devicectl list devices`.
17+
18+
## Workflow
19+
20+
1. Validate repo and tooling.
21+
- Run from repo root and ensure `apps/mobile` exists.
22+
- Verify `pnpm`, `xcrun`, `xcodebuild`, and `eas-cli` are available.
23+
- Verify EAS login:
24+
```bash
25+
cd apps/mobile
26+
pnpm dlx eas-cli whoami
27+
```
28+
2. Resolve target device.
29+
- List paired devices:
30+
```bash
31+
xcrun devicectl list devices
32+
```
33+
- Choose device in this order:
34+
- `$ARGUMENTS` if provided and matches exactly one device.
35+
- Otherwise, first paired iPhone.
36+
3. Trigger local `preview` iOS build.
37+
38+
```bash
39+
mkdir -p .context/preview-install
40+
cd apps/mobile
41+
pnpm dlx eas-cli build -p ios --profile preview --non-interactive --local --output=./build-preview.ipa
42+
cd ../..
43+
cp apps/mobile/build-preview.ipa .context/preview-install/folo-preview.ipa
44+
```
45+
46+
4. Install to device locally.
47+
```bash
48+
unzip -q -o .context/preview-install/folo-preview.ipa -d .context/preview-install/unpacked
49+
APP_PATH=$(find .context/preview-install/unpacked/Payload -maxdepth 1 -name '*.app' -type d | head -n 1)
50+
xcrun devicectl device install app --device "<device-id>" "$APP_PATH"
51+
```
52+
5. Try launching app.
53+
54+
```bash
55+
xcrun devicectl device process launch --device "<device-id>" is.follow --activate
56+
```
57+
58+
- If launch fails due to locked device, instruct the user to unlock iPhone and open `Folo` manually.
59+
60+
## Failure Handling
61+
62+
- If local build fails, report:
63+
- build mode (`local`)
64+
- failing command
65+
- key error message from command output
66+
- If app config fails with `Assets source directory not found ... /out/rn-web`, prebuild assets then retry once:
67+
```bash
68+
pnpm --filter @follow/rn-micro-web-app build --outDir out/rn-web/html-renderer
69+
```
70+
71+
## Output Format
72+
73+
Always return:
74+
75+
1. Build mode (`local`) and final status.
76+
2. Local IPA path.
77+
3. Target device identifier.
78+
4. Install result (`installed` or `failed`) and launch result.
79+
5. Next action for the user if manual action is required.

‎.claude/skills/mobile-release/SKILL.md‎

Lines changed: 114 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,114 @@
1+
---
2+
name: mobile-release
3+
description: Perform a regular mobile release from the dev branch. Gathers commits since last release, updates changelog, bumps version, updates iOS Info.plist, and creates release PR to mobile-main.
4+
disable-model-invocation: true
5+
allowed-tools: Bash, Read, Write, Edit, Glob, Grep
6+
---
7+
8+
# Mobile Regular Release
9+
10+
Perform a regular mobile release. This skill handles the full release workflow from the `dev` branch.
11+
12+
## Pre-flight checks
13+
14+
1. Confirm the current branch is `dev`. If not, abort with a warning.
15+
2. Run `git pull --rebase` in the repo root to ensure the local branch is up to date.
16+
3. Read `apps/mobile/package.json` to get the current `version`.
17+
18+
## Step 1: Gather changes since last release
19+
20+
1. Find the last release tag (both old `mobile@` and new `mobile/v` prefixes exist):
21+
```bash
22+
git tag --sort=-creatordate | grep -E '^mobile[@/]' | head -1
23+
```
24+
2. If no tag found, find the last release commit by matching only the subject line:
25+
```bash
26+
git log --format="%H %s" | grep "^[a-f0-9]* release(mobile): release v" | head -1 | awk '{print $1}'
27+
```
28+
3. Get all commits since the last release on the current branch:
29+
```bash
30+
git log <last-tag-or-commit>..HEAD --oneline --no-merges
31+
```
32+
4. Categorize commits into:
33+
- **Shiny new things** (feat: commits, new features)
34+
- **Improvements** (refactor:, perf:, chore: improvements, dependency updates)
35+
- **No longer broken** (fix: commits, bug fixes)
36+
- **Thanks** (identify external contributor GitHub usernames from commits)
37+
38+
## Step 2: Update changelog
39+
40+
1. Read `apps/mobile/changelog/next.md`.
41+
2. Present the categorized changes to the user and draft the changelog content.
42+
3. Wait for user confirmation or edits before writing.
43+
4. Write the final content to `apps/mobile/changelog/next.md`, following the template format:
44+
45+
```markdown
46+
# What's New in vNEXT_VERSION
47+
48+
## Shiny new things
49+
50+
- description of new feature
51+
52+
## Improvements
53+
54+
- description of improvement
55+
56+
## No longer broken
57+
58+
- description of fix
59+
60+
## Thanks
61+
62+
Special thanks to volunteer contributors @username for their valuable contributions
63+
```
64+
65+
5. Keep `NEXT_VERSION` as the placeholder - it will be replaced by `apply-changelog.ts` during bump.
66+
67+
## Step 3: Execute bump
68+
69+
1. Change directory to `apps/mobile/` and run the bump:
70+
```bash
71+
cd apps/mobile && pnpm bump
72+
```
73+
2. This is an interactive `nbump` command that prompts for version selection. It will:
74+
- Pull latest changes
75+
- Apply changelog (rename next.md to {version}.md, create new next.md from template)
76+
- Format package.json with eslint + prettier
77+
- Bump version in `package.json`
78+
- Update `ios/Folo/Info.plist`:
79+
- Set `CFBundleShortVersionString` to the new version
80+
- Increment `CFBundleVersion` (build number) by 1
81+
- Commit with message `release(mobile): release v{NEW_VERSION}`
82+
- Create branch `release/mobile/{NEW_VERSION}`
83+
- Push branch and create PR to `mobile-main`
84+
85+
## Step 4: Verify
86+
87+
1. Confirm the PR was created successfully by checking the output.
88+
2. Report the new version number and PR URL to the user.
89+
3. Summarize:
90+
- New version: v{NEW_VERSION}
91+
- Changelog highlights
92+
- PR URL
93+
94+
## Post-release (manual steps, inform user)
95+
96+
After the release PR is merged to `mobile-main`:
97+
98+
1. **Trigger production builds** via GitHub Actions `workflow_dispatch`:
99+
- Go to "Build iOS" workflow, select `mobile-main` branch, profile = `production`
100+
- Go to "Build Android" workflow, select `mobile-main` branch, profile = `production`
101+
2. Production builds auto-submit to App Store (via `eas submit`) and Google Play (as draft).
102+
3. After submission, go to App Store Connect and Google Play Console to complete the review/release process.
103+
104+
## Reference
105+
106+
- Bump config: `apps/mobile/bump.config.ts`
107+
- Changelog dir: `apps/mobile/changelog/`
108+
- Changelog template: `apps/mobile/changelog/next.template.md`
109+
- Apply changelog script: `apps/mobile/scripts/apply-changelog.ts`
110+
- EAS config: `apps/mobile/eas.json`
111+
- App config: `apps/mobile/app.config.ts`
112+
- iOS Info.plist: `apps/mobile/ios/Folo/Info.plist`
113+
- CI build iOS: `.github/workflows/build-ios.yml`
114+
- CI build Android: `.github/workflows/build-android.yml`

0 commit comments

Comments
 (0)