// Prepare a psd-tools release: update changelog, open release PR. Use when the user wants to cut a new version.
| name | release |
| description | Prepare a psd-tools release: update changelog, open release PR. Use when the user wants to cut a new version. |
Provided version: $ARGUMENTS
Validate it as a PEP 440 string (e.g. 1.2.3, 1.2.3a1, 1.2.3rc1, 1.2.3.post1).
Note: PEP 440 versions must not start with v — that prefix belongs on the git tag, not
the version string.
Stop and ask the user to correct it if invalid. Store it as VERSION for all subsequent steps.
Analyze the commits listed in Step 1 to recommend the correct next version.
The last tag shown in Step 1 uses a v prefix (e.g. v1.14.3); strip it when computing
the next version so the result is a bare PEP 440 string (e.g. 1.14.4, not v1.14.4).
Apply these semver rules:
X+1.0.0) — any commit that breaks a public API or documented behaviourX.Y+1.0) — any new public feature or API addition, no breaking changesX.Y.Z+1) — bug fixes, security patches, chores, docs, or refactoring onlyShow your reasoning and proposed version to the user, then ask them to confirm or override it. Store the confirmed version as VERSION for all subsequent steps.
Fetch tags:
!git fetch --tags -q || echo "Warning: failed to fetch tags — check network/auth and consider retrying."
Last tag: !git describe --tags --abbrev=0 2>/dev/null || echo "(none)"
Today's date: !date +%Y-%m-%d
Now list the commits since the last release by running one of these commands:
(none): run git log --onelinegit log <LAST_TAG>..HEAD --oneline (substituting the actual tag)You must run this command and review the output before proceeding to Step 0 or Step 2.
Read docs/changelog.rst to understand the current format, then draft a new entry for VERSION
using this RST format:
VERSION (YYYY-MM-DD)
--------------------
- [category] Description (#PR)
Important: The - underline must be at least as long as the title line (RST requirement).
Count the exact characters in VERSION (YYYY-MM-DD) and use that many dashes.
Use these categories (pick the most specific one per bullet):
api — public API additions or changespsd — low-level PSD parsing/writingfix — bug fixesrefactor — internal restructuring, no behaviour changedocs — documentation onlyci — CI/CD, GitHub Actionschore — dependency bumps, tooling, housekeepingsecurity — security fixesGroup related changes. Omit purely internal churn that users won't care about. Reference PR numbers where available.
Show the draft to the user and ask for approval or edits before continuing.
Prepend the approved changelog entry directly after the Changelog header block and the
following blank line, leaving a blank line between the header and the new entry.
git checkout -b release/vVERSION
Then update src/psd_tools/version.py using the Edit tool — replace the existing
__version__ line with:
__version__ = "VERSION"
VERSION is the bare PEP 440 string without the v prefix (e.g. 1.15.0, not v1.15.0).
Then stage both changed files and commit:
git add docs/changelog.rst src/psd_tools/version.py
git commit -m "docs: release vVERSION"
git push -u origin release/vVERSION
Replace VERSION with the actual version string (e.g. 1.15.0).
Run gh pr create with --title "Release vVERSION" and a --body containing:
## Release vVERSION heading### Changelog section with the approved entry from Step 2 pasted in### Release checklist section with these items:
[ ] Changelog entry reviewed and accurate[ ] Version follows PEP 440auto-tag workflow will tag the merge commit
as vVERSION and the release workflow will build wheels and publish to PyPI automatically."Replace VERSION with the actual version string throughout.
Print the PR URL. Remind the user:
After the PR is approved and merged, the
auto-tagGitHub Actions workflow tags the merge commit asvVERSIONautomatically. That tag push triggers thereleaseworkflow to build wheels for all platforms and publish to PyPI. No manual tagging or publishing is needed.
Replace VERSION with the actual version string.