Release hygiene for 2.1.3: date the notes, document the entropy fix, cite upstream

[energyscholar]

The code for 2.1.3 is done and main is green. This is the paperwork, plus the one step that only you can take.

What this changes

1. The changelog says ## [2.1.3] — unreleased. Tag it as-is and the shipped release notes announce that the release hasn't happened. Now dated.

2. The compute_entropy fix (88e7f38) is missing from the notes. It landed after they were written, and it's the entry a 2.1.3 user most needs, because this is the release that lifts the numpy<2 ceiling — which is what puts people on the stack where EntropyHub's np.NaN break appears. It was also a partial break (method='sample' fine, method='kolmogorov' raising AttributeError), and partial breaks stay hidden until someone reaches for the failing path. Now documented under Fixed.

3. core.py claimed the EntropyHub bug was "(reported upstream)" with no reference. I checked before trusting it: we filed nothing there. A report does exist — EntropyHub#21, opened 2026-07-15 by a third party, still open, and EntropyHub's latest release is still 2.0 — so the claim was true in substance and misleading in attribution. Now cited by number, so whoever eventually removes the shim has a tracking link rather than a rumour.

The 30 vs 31 test count in the verification table is left as measured. Those container runs predate the entropy regression test; re-labelling numbers we didn't re-run would be worse than explaining them, so a note explains them.

No functional change. Suite green: 31 passed, 1 skipped.

The remaining step, which is yours

publish-pypi authenticates by OIDC trusted publishing, so it needs a publisher registered on the PyPI project. That page is Owner-only — I'm a maintainer, so I can't:

https://pypi.org/manage/project/ewstools/settings/publishing/
  Owner            : ThomasMBury
  Repository name  : ewstools
  Workflow filename: release.yml
  Environment name : pypi

Worth doing Actions ▸ Release ▸ Run workflow ▸ target testpypi first if you set up the TestPyPI side too — it exercises the whole path without touching real PyPI.

Once the publisher is registered, tagging does the rest:

git tag v2.1.3 && git push origin v2.1.3

The build job fails loudly if the tag and pyproject.toml disagree, before anything is uploaded. If the publisher isn't registered the OIDC exchange just fails — nothing uploads, and the tag can be deleted and re-pushed. The only irreversible step is a successful publish: PyPI version numbers can be yanked but never reused.

Happy to push the tag myself once you've done the PyPI side — say the word. It's your package; I didn't want to cut a release under your name without you saying so.

One promise outstanding either way: I told Olivier on #474 that I'd comment there once 2.1.3 is on PyPI so he knows to drop the workaround. I'll do that when it lands.

[ThomasMBury]

Thanks, Bruce. I’ve reviewed this, and the changelog and documentation updates make sense.

I’ve now registered GitHub as a Trusted Publisher for ewstools on PyPI using:

• Owner: ThomasMBury
• Repository: ewstools
• Workflow: release.yml
• Environment: pypi

Please go ahead and push the v2.1.3 tag once this PR is merged, and verify that the release workflow completes successfully. A TestPyPI run first is fine if you think it is worthwhile, but I’m also comfortable proceeding directly to PyPI.

Thanks also for following up with Olivier on #474 once the release is available.

[ThomasMBury]

One further update: I’ve now also registered the same workflow as a Trusted Publisher on TestPyPI, using the testpypi environment.

So the TestPyPI dry run should now be ready whenever you are. If it succeeds, please go ahead with the v2.1.3 tag and production release.