Automate releases, and cut 2.3.0

[guilyx]

The actual problem

PyPI has been serving jupyddl 0.4.1 — the original Julia-backed wrapper — since long before the pure-Python rewrite landed. There was no release automation and nobody published by hand, so pip install jupyddl has been handing people a different library than this repository documents, across four minor versions (1.0.0, 2.0.0, 2.1.0, 2.2.0).

The README says pip install jupyddl and then describes a dependency-free planning framework. Today that install gives you something that wants Julia.

What lands

.github/workflows/release.yml — push a tag, get a release:

git tag -a v2.3.0 -m "jupyddl 2.3.0" && git push origin v2.3.0

Build → verify → publish to PyPI → cut the GitHub Release from that version's changelog section.

Authentication is PyPI Trusted Publishing (OIDC), so there is no API token in this repository to leak, rotate, or forget about. That trade costs one piece of setup only a PyPI maintainer can do — see below.

Four things it refuses to do

Each is a way a release goes wrong quietly, and PyPI never lets you take a version back:

Refusal	Why it matters
Tag disagrees with pyproject.toml	publishing 2.3.0 from a v2.4.0 tag is unfixable
jupyddl.__version__ disagrees with the metadata	a package reporting a different version at runtime is a support ticket with no obvious cause
twine check --strict objects	malformed metadata renders as raw text on the project page, fixable only by another release
The built wheel does not work	it is installed into a clean venv, away from the source tree, and made to generate and solve an instance — which is what catches a module missing from the wheel

workflow_dispatch runs the same pipeline against TestPyPI, so this workflow can be changed without spending a real version number.

The pypi job is the only one gated on the trusted publisher, so a tag pushed before that setup exists still produces verified artifacts rather than a half-finished release.

⚠️ One-time setup only a maintainer can do

The pypi job will fail until this exists. On https://pypi.org/manage/project/jupyddl/settings/publishing/:

Field	Value
Owner	APLA-Toolbox
Repository name	PythonPDDL
Workflow name	release.yml
Environment name	pypi

The environment name is load-bearing — PyPI rejects a token minted from anywhere else, which is what stops a workflow added later by someone else from publishing.

Optionally add yourself as a required reviewer on the pypi environment if you would rather a mistaken tag not reach PyPI unattended.

Full runbook in docs/RELEASING.md.

2.3.0

Closes the changelog section that accumulated the learned heuristics, the RL stage, and the CI work. Metadata filled out for a listing people will actually read: Python 3.9–3.14 classifiers, audience and status, changelog/issues/workbench URLs, and a real pip install jupyddl block in the README.

Two deliberate omissions:

• Development Status is Beta, not Stable — jupyddl.learn is new and its API will move.
• No Typing :: Typed classifier — there is no py.typed marker and the annotations are not complete enough to claim one.

Verified locally, end to end

• Builds; twine check --strict passes on both sdist and wheel.
• Version guards accept v2.3.0 and refuse v2.4.0.
• Changelog extraction pulls the right 4466 characters.
• Wheel installs into a clean environment and solves an instance, reporting 2.3.0.
• 415 tests green, flake8 and black clean, all five workflow files parse.

---

Generated by Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request