// Release a new version of Wikipedia-API. Use this skill whenever the user mentions releasing, publishing, cutting a new version, bumping the version, or preparing a release of Wikipedia-API — even if they just say "let's do a release" or "time to release".
| name | wikipedia-api-release |
| description | Release a new version of Wikipedia-API. Use this skill whenever the user mentions releasing, publishing, cutting a new version, bumping the version, or preparing a release of Wikipedia-API — even if they just say "let's do a release" or "time to release". |
Read two files:
wikipediaapi/_version.py — extract the version tuple, e.g. (0, 14, 1) → 0.14.1CHANGES.rst — extract every bullet point listed under the Unreleased heading
(everything between the Unreleased\n---------- heading and the next version heading)If there is no Unreleased section in CHANGES.rst, tell the user and stop —
there is nothing to release.
If the Unreleased section is empty (no bullet points), warn the user that the
changelog has no entries and ask whether they want to continue anyway.
Classify the unreleased changes and propose a version:
| Change type | Bump |
|---|---|
| Bug fixes, docs, tests, dependency updates, tooling, refactors | Patch — X.Y.(Z+1) |
| New feature, new API method, new CLI command, new property, new parameter | Minor — X.(Y+1).0 |
| Breaking change, removed API, incompatible behaviour change | Major — (X+1).0.0 |
When in doubt between patch and minor, lean toward minor — it is easier to release more minor versions than to explain to users why a feature landed in a patch.
Present a clear summary to the user, for example:
Current version: 0.14.1
Unreleased changes:
• Rewrite SKILLS/ as flat Markdown reference files - PR 552
• Replace release process with PR-based flow - PR 553
• Use Unreleased section in CHANGES.rst for development workflow - PR 553
Suggestion: 0.15.0 (minor — new tooling and development workflow)
Version to release? [0.15.0]
Wait for the user to respond:
y / yes → use the suggested versionX.Y.Z string → use that insteadValidate that the chosen version:
X.Y.Z formatIf validation fails, explain why and ask again.
Make sure the user is on a clean master branch (the Makefile will enforce
this too, but it is friendly to mention it up front). Then run:
make prepare-release VERSION='<confirmed-version>'
This will:
release/<version> branchUnreleased → <version> in CHANGES.rst and bump all version filesKeep the user informed of progress. The checks can take a few minutes.
If make prepare-release fails, read the error output carefully and explain
what went wrong. Common causes: not on master, dirty working tree, a failing
test, or a linting error.
On the release/<version> branch, re-record all CLI snapshot fixtures so they
reflect any output changes (e.g. version string, User-Agent, help text) in this
release:
make run-test-cli-record
make run-test-cli-verify
make run-tests
If run-test-cli-verify passes, commit and push the updated fixtures:
git add tests/cli/expected/
git commit -m "test(cli): update fixtures for v<version>"
git push
Tell the user:
The release PR is open. Once it's reviewed and merged, let me know
and I'll create the GitHub Release.
Wait for the user to confirm the PR has been merged before proceeding.
Run:
make create-github-release VERSION='<confirmed-version>'
This creates a v<version> tag and a GitHub Release with auto-generated
release notes drawn from merged PRs. The release.yml workflow then
automatically publishes the package to PyPI.
Confirm with the user that the release is complete and point them to the GitHub Release page.