release

Create SDK Release

Bumps the SDK version, generates release notes in HISTORY.md, and commits on a dedicated release branch.

Usage

• /release patch — bump patch version (e.g., 9.2.1 → 9.2.2)
• /release minor — bump minor version (e.g., 9.2.1 → 9.3.0)
• /release major — bump major version (e.g., 9.2.1 → 10.0.0)
• /release 9.3.0 — set an explicit version

If no argument is provided, default to patch.

Instructions

1. Determine the new version

Read the current version from pyatlan/version.txt. Parse the argument to compute the new version:

• patch: increment the third number, e.g., 9.2.1 → 9.2.2
• minor: increment the second number, reset patch, e.g., 9.2.1 → 9.3.0
• major: increment the first number, reset minor and patch, e.g., 9.2.1 → 10.0.0
• If the argument matches a semver pattern (e.g., 9.3.0), use it directly

Confirm the new version with the user before proceeding.

---

2. Gather changes since last release

Always gather from origin/main — that's where PRs are merged. The current working branch is irrelevant here.

Step 1 — find the last release commit on main and list everything since it:

git fetch origin main --quiet
git log --oneline $(git log --oneline origin/main | grep "\[release\]" | head -1 | awk '{print $1}')..origin/main

Step 2 — extract PR numbers from merge commits and fetch details for each:

git log --oneline $(git log --oneline origin/main | grep "\[release\]" | head -1 | awk '{print $1}')..origin/main | grep "Merge pull request" | grep -oE '#[0-9]+' | tr -d '#'

Then for each PR number, run:

gh pr view <number> --json title,labels,body,mergedAt

If gh is not authenticated, fall back to the commit subjects alone — do NOT skip this step or silently use an empty list. Note any PRs you couldn't fetch so the user knows the notes may be incomplete.

Step 3 — also run this to catch non-merge commits (direct pushes, fixups, etc.):

git log --oneline --no-merges $(git log --oneline origin/main | grep "\[release\]" | head -1 | awk '{print $1}')..origin/main