|
| 1 | +--- |
| 2 | +name: release-version |
| 3 | +description: Use when releasing a new version - guides through version bump, changelog generation, commit grouping, tagging, and GitHub CI tracking. Triggers on "发布新版本", "release", "发版", or version release requests. |
| 4 | +--- |
| 5 | + |
| 6 | +# Release Version Workflow |
| 7 | + |
| 8 | +## Overview |
| 9 | + |
| 10 | +A complete release workflow for Gemini-Subtitle-Pro that handles version bumping, changelog generation from git history, grouped commits, tagging, and GitHub CI monitoring. |
| 11 | + |
| 12 | +## When to Use |
| 13 | + |
| 14 | +- User says "发布新版本", "release", "发版" |
| 15 | +- User requests a version release |
| 16 | +- Before publishing a new release to GitHub |
| 17 | + |
| 18 | +## Workflow Steps |
| 19 | + |
| 20 | +### Step 0: Pre-flight Questions |
| 21 | + |
| 22 | +Ask the user: |
| 23 | + |
| 24 | +1. **Version number** - What version to release? (e.g., 2.12.0) |
| 25 | +2. **Pre-release?** - Is this a pre-release version? (affects GitHub release settings) |
| 26 | + |
| 27 | +### Step 1: Check and Commit Uncommitted Changes |
| 28 | + |
| 29 | +1. Run `git status` to check for uncommitted changes |
| 30 | +2. If changes exist: |
| 31 | + - Analyze the changes by topic/feature |
| 32 | + - Group related changes together |
| 33 | + - Create separate commits for each topic group |
| 34 | + - Use conventional commit messages (feat:, fix:, chore:, etc.) |
| 35 | + |
| 36 | +### Step 2: Generate Changelog |
| 37 | + |
| 38 | +1. Find the previous version tag: |
| 39 | + |
| 40 | + ```bash |
| 41 | + git describe --tags --abbrev=0 |
| 42 | + ``` |
| 43 | + |
| 44 | +2. Get all commits since last tag: |
| 45 | + |
| 46 | + ```bash |
| 47 | + git log <previous-tag>..HEAD --oneline |
| 48 | + ``` |
| 49 | + |
| 50 | +3. Read each commit's details to categorize: |
| 51 | + - **Features** - New functionality (feat:) |
| 52 | + - **Fixes** - Bug fixes (fix:) |
| 53 | + - **Refactor** - Code improvements (refactor:) |
| 54 | + - **Chore** - Maintenance tasks (chore:) |
| 55 | + - **Documentation** - Doc updates (docs:) |
| 56 | + - **Performance** - Performance improvements (perf:) |
| 57 | + |
| 58 | +4. Update `CHANGELOG.md`: |
| 59 | + - Add new version section at the top (after header) |
| 60 | + - Format: `## [X.X.X] - YYYY-MM-DD` (no 'v' prefix) |
| 61 | + - Group entries by category (Keep a Changelog format) |
| 62 | + |
| 63 | +5. Update `package.json`: |
| 64 | + - Change `"version": "X.X.X"` to new version (no 'v' prefix) |
| 65 | + |
| 66 | +### Step 3: Commit Release Files |
| 67 | + |
| 68 | +```bash |
| 69 | +git add CHANGELOG.md package.json |
| 70 | +git commit -m "Release vX.X.X" |
| 71 | +``` |
| 72 | + |
| 73 | +Note: Commit message uses 'v' prefix, but version strings in files do not. |
| 74 | + |
| 75 | +### Step 4: Tag and Push |
| 76 | + |
| 77 | +```bash |
| 78 | +git tag vX.X.X |
| 79 | +git push origin main |
| 80 | +git push origin vX.X.X |
| 81 | +``` |
| 82 | + |
| 83 | +Note: Tag uses 'v' prefix (e.g., v2.12.0). |
| 84 | + |
| 85 | +### Step 5: Monitor GitHub CI |
| 86 | + |
| 87 | +1. Track the GitHub Actions workflow: |
| 88 | + |
| 89 | + ```bash |
| 90 | + gh run list --workflow=release.yml --limit=1 |
| 91 | + gh run watch <run-id> |
| 92 | + ``` |
| 93 | + |
| 94 | +2. Report build status to user: |
| 95 | + - Success: Provide release URL |
| 96 | + - Failure: Show error details |
| 97 | + |
| 98 | +## Quick Reference |
| 99 | + |
| 100 | +| Step | Command | Purpose | |
| 101 | +| ------------ | -------------------------------- | -------------------------- | |
| 102 | +| Check status | `git status` | Find uncommitted changes | |
| 103 | +| Previous tag | `git describe --tags --abbrev=0` | Get last release tag | |
| 104 | +| Commit log | `git log <tag>..HEAD --oneline` | List changes since release | |
| 105 | +| Create tag | `git tag vX.X.X` | Create version tag | |
| 106 | +| Push tag | `git push origin vX.X.X` | Trigger CI build | |
| 107 | +| Watch CI | `gh run watch` | Monitor build progress | |
| 108 | + |
| 109 | +## Version Format Rules |
| 110 | + |
| 111 | +| Location | Format | Example | |
| 112 | +| -------------- | --------------- | -------------------------- | |
| 113 | +| Git tag | With 'v' prefix | `v2.12.0` | |
| 114 | +| Commit message | With 'v' prefix | `Release v2.12.0` | |
| 115 | +| CHANGELOG.md | No 'v' prefix | `## [2.12.0] - 2026-01-06` | |
| 116 | +| package.json | No 'v' prefix | `"version": "2.12.0"` | |
| 117 | + |
| 118 | +## CHANGELOG Format |
| 119 | + |
| 120 | +```markdown |
| 121 | +## [X.X.X] - YYYY-MM-DD |
| 122 | + |
| 123 | +### Features |
| 124 | + |
| 125 | +- **Component**: Description of new feature. |
| 126 | + |
| 127 | +### Fixes |
| 128 | + |
| 129 | +- **Component**: Description of bug fix. |
| 130 | + |
| 131 | +### Refactor |
| 132 | + |
| 133 | +- **Component**: Description of refactoring. |
| 134 | + |
| 135 | +### Chore |
| 136 | + |
| 137 | +- **Component**: Maintenance description. |
| 138 | +``` |
| 139 | + |
| 140 | +## Common Mistakes |
| 141 | + |
| 142 | +| Mistake | Fix | |
| 143 | +| ----------------------------- | ----------------------------------------------------------- | |
| 144 | +| Forgetting to push the tag | CI only triggers on tag push, not commit push | |
| 145 | +| Wrong version in package.json | Version must match tag (without 'v' prefix) | |
| 146 | +| Changelog in wrong position | New version goes after the header, before previous versions | |
| 147 | +| Not grouping commits | Related changes should be in one commit for cleaner history | |
| 148 | +| Inconsistent 'v' prefix | Tag and commit use 'v', files don't | |
| 149 | + |
| 150 | +## Pre-release Handling |
| 151 | + |
| 152 | +For pre-release versions: |
| 153 | + |
| 154 | +- Use version format: `X.X.X-beta.1`, `X.X.X-rc.1` |
| 155 | +- Tag format: `vX.X.X-beta.1` |
| 156 | +- Note: Current CI workflow sets `prerelease: false` - may need manual adjustment in GitHub release |
0 commit comments