|
| 1 | +--- |
| 2 | +name: release |
| 3 | +description: Create a new SDK release β bump version, update HISTORY.md, commit, and tag |
| 4 | +allowed-tools: Read, Bash, Edit, Write, Glob, Grep, Agent, WebFetch |
| 5 | +--- |
| 6 | + |
| 7 | +# Create SDK Release |
| 8 | + |
| 9 | +Bumps the SDK version, generates release notes in HISTORY.md, commits, and creates a git tag. |
| 10 | + |
| 11 | +## Usage |
| 12 | + |
| 13 | +- `/release patch` β bump patch version (e.g., 9.2.1 β 9.2.2) |
| 14 | +- `/release minor` β bump minor version (e.g., 9.2.1 β 9.3.0) |
| 15 | +- `/release major` β bump major version (e.g., 9.2.1 β 10.0.0) |
| 16 | +- `/release 9.3.0` β set an explicit version |
| 17 | + |
| 18 | +If no argument is provided, default to `patch`. |
| 19 | + |
| 20 | +## Instructions |
| 21 | + |
| 22 | +### 1. Determine the new version |
| 23 | + |
| 24 | +Read the current version from `pyatlan/version.txt`. Parse the argument to compute the new version: |
| 25 | + |
| 26 | +- `patch`: increment the third number, e.g., `9.2.1` β `9.2.2` |
| 27 | +- `minor`: increment the second number, reset patch, e.g., `9.2.1` β `9.3.0` |
| 28 | +- `major`: increment the first number, reset minor and patch, e.g., `9.2.1` β `10.0.0` |
| 29 | +- If the argument matches a semver pattern (e.g., `9.3.0`), use it directly |
| 30 | + |
| 31 | +Confirm the new version with the user before proceeding. |
| 32 | + |
| 33 | +--- |
| 34 | + |
| 35 | +### 2. Gather changes since last release |
| 36 | + |
| 37 | +Run: |
| 38 | +```bash |
| 39 | +git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD |
| 40 | +``` |
| 41 | + |
| 42 | +If no tags exist, use all commits on the current branch. This gives you the list of changes to summarize. |
| 43 | + |
| 44 | +Also check merged PRs for additional context: |
| 45 | +```bash |
| 46 | +gh pr list --state merged --base main --limit 30 --json title,labels,number,mergedAt |
| 47 | +``` |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +### 3. Draft release notes |
| 52 | + |
| 53 | +Write the release notes following HISTORY.md conventions exactly: |
| 54 | + |
| 55 | +**Header format:** |
| 56 | +``` |
| 57 | +## X.Y.Z (Month Day, Year) |
| 58 | +``` |
| 59 | + |
| 60 | +Use the current date. Month is full name, day has no leading zero. |
| 61 | + |
| 62 | +**Section order** (only include sections that have content): |
| 63 | + |
| 64 | +1. `### New Features` β new functionality |
| 65 | +2. `### Breaking Changes` β breaking API changes |
| 66 | +3. `### Experimental: pyatlan_v9` β v9-specific changes |
| 67 | +4. `### Bug Fixes` β bug fixes |
| 68 | +5. `### Packages` β dependency updates |
| 69 | +6. `### QOL Improvements` β catch-all for misc improvements |
| 70 | + |
| 71 | +**Formatting rules:** |
| 72 | +- Use dashes (`-`) for bullet points |
| 73 | +- Bold the key phrase at the start: `- **Short description**: Detailed explanation.` |
| 74 | +- Be concise but thorough β describe what changed and why it matters |
| 75 | +- Group related changes into single bullets where it makes sense |
| 76 | + |
| 77 | +Present the draft to the user for review and iterate until approved. |
| 78 | + |
| 79 | +--- |
| 80 | + |
| 81 | +### 4. Update version.txt |
| 82 | + |
| 83 | +Write the new version number to `pyatlan/version.txt` (single line, no trailing newline beyond what was there). |
| 84 | + |
| 85 | +--- |
| 86 | + |
| 87 | +### 5. Update HISTORY.md |
| 88 | + |
| 89 | +Prepend the new release notes to the top of `HISTORY.md`, followed by a blank line before the previous release. |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +### 6. Commit and tag |
| 94 | + |
| 95 | +```bash |
| 96 | +git add pyatlan/version.txt HISTORY.md |
| 97 | +git commit -m "[release] Bumped to release X.Y.Z" |
| 98 | +git tag vX.Y.Z |
| 99 | +``` |
| 100 | + |
| 101 | +The commit message must follow the exact pattern: `[release] Bumped to release X.Y.Z` |
| 102 | + |
| 103 | +The tag must be `vX.Y.Z` (with the `v` prefix) β this is validated by `check_tag.py` during publishing. |
| 104 | + |
| 105 | +--- |
| 106 | + |
| 107 | +### 7. Push |
| 108 | + |
| 109 | +Ask the user before pushing. When confirmed: |
| 110 | + |
| 111 | +```bash |
| 112 | +git push && git push --tags |
| 113 | +``` |
| 114 | + |
| 115 | +--- |
| 116 | + |
| 117 | +## Notes |
| 118 | + |
| 119 | +- The version in `pyatlan/version.txt` is the single source of truth β `pyproject.toml` reads it dynamically |
| 120 | +- The git tag must match the version (`vX.Y.Z` β `X.Y.Z`) β enforced by `check_tag.py` in CI |
| 121 | +- GitHub's `release.yml` auto-categorizes PRs by label into GitHub release notes, but `HISTORY.md` is the canonical changelog maintained manually |
| 122 | +- After pushing the tag, a GitHub Release should be created (manually or via GitHub UI) to trigger the PyPI publish workflow |
0 commit comments