Skip to content

Commit 0270087

Browse files
authored
Merge pull request #848 from atlanhq/bump-to-release-9.2.2
[release] Bumped to release 9.2.2
2 parents 3969ddb + 31311e2 commit 0270087

3 files changed

Lines changed: 130 additions & 1 deletion

File tree

Lines changed: 122 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
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

β€ŽHISTORY.mdβ€Ž

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,10 @@
1+
## 9.2.2 (March 11, 2026)
2+
3+
### QOL Improvements
4+
5+
- **`PackageHeaders` model and backward-compatible header emission**: Introduced a typed `PackageHeaders` model to manage package-related HTTP headers. `set_package_headers` now accepts explicit header values, and the SDK emits both `package-name` and `app-name` headers to maintain backward compatibility with older backends.
6+
- **`/release` skill**: Added a Claude Code skill to automate SDK releases β€” bumps version, drafts release notes, commits, and tags.
7+
18
## 9.2.1 (March 10, 2026)
29

310
### Experimental: `pyatlan_v9`

β€Žpyatlan/version.txtβ€Ž

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
9.2.1
1+
9.2.2

0 commit comments

Comments
Β (0)