wikipedia-api-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".

Wikipedia-API Release

Step 1 — Read current state

Read two files:

1. wikipediaapi/_version.py — extract the version tuple, e.g. (0, 14, 1) → 0.14.1
2. CHANGES.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.

Step 2 — Suggest a version bump

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]

Step 3 — Confirm the version

Wait for the user to respond:

• Empty / y / yes → use the suggested version
• Any X.Y.Z string → use that instead

Validate that the chosen version:

• Follows X.Y.Z format
• Is strictly greater than the current version

If validation fails, explain why and ask again.

Step 4 — Run prepare-release

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:

• Run the full pre-release check suite (tests, type checks, linting, examples)
• Create a release/<version> branch
• Rename Unreleased → <version> in CHANGES.rst and bump all version files
• Open a pull request

Keep 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.

Step 5 — Re-record CLI test fixtures

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

Step 6 — Wait for the PR to merge

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.

Step 7 — Create the GitHub Release

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.