Repository navigation
Let a changelog with a release level be found - #2100
Merged
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A changelog whose version carries a release level —
WinPythondot-64bit-3.14.7.1b1.md— is invisible tofind_previous_version, so the history of the next release is compared against the wrong baseline.The cause
find_previous_versionreads the previous release out of the file names inchangelogs/, through([0-9\.]+)\.(txt|md). A version with a release level has letters in it, so it matches nothing and is skipped.The ordering never needed anything — PEP 440 already places them correctly:
Only the name pattern was wrong. Names now go to the version parser, and whatever does not parse as a version is skipped, which drops the
_History.mdcompanions by the same rule rather than relying on the digit class to exclude them.This is live, not hypothetical
WinPythondot-64bit-3.9.0.0b1.mdhas been inchangelogs/for years, unseen. Against the real directory:3.9.0.03.8.10.03.9.0.0b13.14.7.13.14.7.03.14.7.03.14.7.1b13.14.7.03.14.7.0So 3.9.0.0's history was diffed against 3.8.10.0 and reported the beta's changes a second time. Nothing else in the directory answers differently.
copy_changelogscarried the same pattern and now selects on the parsed version instead of a string prefix, so a level travels with its cycle and3.1cannot pick up3.15.Why now
The cycle build (#2098) will start producing changelogs for beta cycles, and the file name is the only thing carrying the version. This has to work before a
b1is published, whichever way the naming question is settled — the fix is correct on its own terms either way.Testing
tests/test_diff_versions.py, 20 tests on synthetic directories: level ordering in both directions, the five levels WinPython has used (b1 b2 rc1 a1 post1),_Historynever being picked,.txtchangelogs still counting, the documented "nothing earlier returns the target itself" fallback, and the separations that matter —dot/slim,dot/dotf, flavored/unflavored, 32/64 bit.Mutation-checked: restoring the old pattern fails exactly the 8 level-related tests and leaves the other 12 green. Full suite 183 passed.
Independent of #2099 — no shared files, no ordering constraint.
🤖 Generated with Claude Code
https://claude.ai/code/session_01MBk5k7WdpPvx4SUFyEk3U3