Prepare the 0.3.0 release - #39
Conversation
Ten commits since 0.2.0, all user-facing, and none of them reachable except by installing from git. Two change command-line behavior -- --pairguide auto is gone, and mle now refuses the disabled Bayes options rather than ignoring them -- so they need a version number rather than arriving silently in a checkout. Noted at the top of the section. Also stop the sdist carrying a compiled helper. data_files names rra/bin/RRA and gsea/bin/mageckGSEA, which setuptools pulls into the sdist, so building one from a tree where the tests had been run shipped that platform's binaries. The published 0.2.0 is unaffected -- the release workflow builds from a never-compiled checkout -- and make relinks regardless, since the object files are not shipped. Excluding them makes a local `python -m build` reproduce what CI produces. Rehearsed the release path end to end: sdist builds clean with no binaries and the C++ sources intact, twine check passes, installing strictly from the tarball into a fresh venv compiles the helpers, mageck2 --version reports 0.3.0, and the 49 shipped tests pass against the installed package. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 56c9a78957
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## [Unreleased] | ||
|
|
||
| ## [0.3.0] - 2026-08-31 |
There was a problem hiding this comment.
The new reference-style [0.3.0] heading has no corresponding link definition, and the existing [Unreleased] definition at the bottom still compares v0.2.0...HEAD. After the v0.3.0 tag is published, the release heading will not link to its changes and the Unreleased link will continue including the entire 0.3.0 release; add a v0.2.0...v0.3.0 definition and advance Unreleased to v0.3.0...HEAD.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed and fixed in 097afba — a genuine oversight, and both halves of it mattered.
[Unreleased]: .../compare/v0.3.0...HEAD (was v0.2.0...HEAD)
[0.3.0]: .../compare/v0.2.0...v0.3.0 (new)
Without the second line the heading would have rendered as literal [0.3.0] while every other version links to its diff; without the first, Unreleased would have kept reporting the entire 0.3.0 release as unreleased after the tag was cut — and that one would have quietly persisted into 0.4.0.
Verified every heading now resolves and no definition is orphaned:
Unreleased OK 0.3.0 OK 0.2.0 OK 0.1.0 OK orphan definitions: none
Worth noting this is a class of defect the test suite cannot see at all — the release rehearsal I ran covers the sdist, the install, and the shipped tests, but nothing checks that CHANGELOG references resolve. Good catch.
The new heading is a reference-style link with no definition, so it would render as literal text while every other version links to its diff. Unreleased also still spanned v0.2.0...HEAD, which would have kept reporting the whole 0.3.0 release as unreleased after the tag. Reported by Codex review on #39. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Ten commits have landed since v0.2.0 (Jul 10), all user-facing, and none of them reachable except by installing from git — which is what we have been telling users to do in #15.
mageck2/version.py→0.3.0(single source;pyproject.tomlreads it)[Unreleased]→[0.3.0] - 2026-08-31, with a short note at the top of the section naming the two behavior changesTwo breaking changes, which is why this needs a version
--pairguide autois no longer accepted (Disable --pairguide auto and validate extraction windows up front #33)mlerefuses-p/--PPI-prior,-w/--PPI-weighting,-e/--negative-controlinstead of ignoring them (Refuse the disabled Bayes options instead of ignoring them #37)Both previously ran to completion and produced output that did not reflect the option given. Neither should reach users as an unannounced change in a git checkout.
Also: stop the sdist carrying a compiled helper
data_filesnamesrra/bin/RRAandgsea/bin/mageckGSEA, which setuptools pulls into the sdist. Building one locally from a tree where the tests had been run therefore shipped that platform's binaries — I hit this while rehearsing, and the tarball contained macOS builds.The published 0.2.0 is unaffected: the release workflow builds from a fresh checkout where those paths hold only
.gitkeep, and I confirmed the PyPI tarball has no binaries.makealso relinks regardless, since the object files are not shipped. So this is a local-build hazard rather than a shipped bug — but excluding them makespython -m buildlocally reproduce what CI produces, which is what you want before tagging.Release path rehearsed end to end
Not just the unit tests — the actual
verifyjob's steps:The extracted tree has no compiled helpers, so
tests/conftest.pycorrectly falls back and the suite exercises the installed binaries — which is what a release gate should check.Not done here
No tag and no GitHub Release. Publishing to PyPI is irreversible — a version number cannot be reused — so that step is yours to trigger once this merges.