Release
Cut a new pymobiledevice3 release — create the GitHub release (which publishes to PyPI) with a curated Highlights section. Use when asked to "release vX.Y.Z", "cut a release", or "publish a new version".From its SKILL.md
npx -y skills add doronz88/pymobiledevice3 --skill releaseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.5 KB, as published. Nobody here has run it
Releasing pymobiledevice3
How releasing works here
- Version is derived from the git tag via
setuptools_scm(pyproject.toml→[tool.setuptools_scm],version = { attr = "pymobiledevice3._version.__version__" }). There is no version string to bump in any file — the tag is the version. - PyPI publish is triggered by creating a GitHub release, not by pushing a tag.
See
.github/workflows/python-publish.yml(on: release: types: [created]). It runsuv build(needs full history forsetuptools_scm) and publishes via trusted publishing. - Tags are
vMAJOR.MINOR.PATCH(e.g.v9.32.1). Patch = bug-fix-only; minor = new features.
Steps
-
Confirm the tree is clean and pushed.
git statusshould be clean and up to date withorigin/master. The release is cut frommaster. -
Review what's shipping so you can write accurate highlights:
PREV=$(git tag --sort=-creatordate | head -1) git log $PREV..HEAD --oneline git show <sha> # inspect each meaningful change to describe it correctly -
Create the release (this triggers the PyPI publish). Use
--target master, not a raw SHA — targeting a bare commit SHA fails withRelease.target_commitish is invalid:gh release create vX.Y.Z --target master --title vX.Y.Z --generate-notes -
Add a curated
## Highlightssection above## What's Changed.--generate-notesalone does NOT include highlights — every prior release has a hand-written one, so always add it. Match the house style (seegh release view v9.32.0):- One
###subsection per notable change, prefixed with an emoji:✨new feature ·🐛bug fix ·📚/📝docs · other emoji as fitting. - A short prose paragraph explaining the user-visible impact, plus a fenced
shellexample for new commands/features.
- One
-
Rewrite
## What's Changedas a commit history, not the PR-link list--generate-notesproduces. One line per commit since the previous tag, formatted* <shortsha8> <subject> (#<pr>) (@<committer>):for sha in $(git log $PREV..HEAD --format='%H'); do short=$(git rev-parse --short=8 $sha) subj=$(git show -s --format='%s' $sha) login=$(gh api repos/doronz88/pymobiledevice3/commits/$sha --jq '.author.login') pr=$(gh api repos/doronz88/pymobiledevice3/commits/$sha/pulls --jq '.[0].number') echo "* $short $subj (#$pr) (@$login)" doneKeep the generated
## New Contributorsand**Full Changelog**lines.Write the full body (Highlights + What's Changed + New Contributors + Full Changelog) to a file and apply it:
gh release edit vX.Y.Z --notes-file /tmp/rel_notes.mdEditing notes does not re-trigger the publish workflow — it already fired on creation.
-
Verify the publish workflow.
gh run list --workflow=python-publish.yml --limit 3Watch it to
completed / successif the user wants confirmation it landed on PyPI.
Notes
ghmust be installed and authenticated (gh auth status).- Don't create the tag manually with
git tag—gh release createcreates both the tag and the release. A lone tag push will not publish to PyPI.