Skip to content

Let a changelog with a release level be found - #2100

Merged
stonebig merged 1 commit into
winpython:masterfrom
stonebig:fix-changelog-release-level
Sep 6, 2026
Merged

stonebig merged 1 commit into
winpython:masterfrom
stonebig:fix-changelog-release-level

Conversation

@stonebig

@stonebig stonebig commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

A changelog whose version carries a release level — WinPythondot-64bit-3.14.7.1b1.md — is invisible to find_previous_version, so the history of the next release is compared against the wrong baseline.

The cause

find_previous_version reads the previous release out of the file names in changelogs/, 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:

3.14.7.0  <  3.14.7.1b1  <  3.14.7.1

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.md companions 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.md has been in changelogs/ for years, unseen. Against the real directory:

target before after
3.9.0.0 3.8.10.0 3.9.0.0b1
3.14.7.1 3.14.7.0 3.14.7.0
3.14.7.1b1 3.14.7.0 3.14.7.0

So 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_changelogs carried the same pattern and now selects on the parsed version instead of a string prefix, so a level travels with its cycle and 3.1 cannot pick up 3.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 b1 is 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), _History never being picked, .txt changelogs 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

find_previous_version reads the previous release out of the file names in
changelogs/, through a pattern of digits and dots. A version carrying a
release level has letters in it, so 3.14.7.1b1 matched nothing and the
comparison walked straight past it.

The ordering never needed anything: PEP 440 already puts 3.14.7.0 before
3.14.7.1b1 before 3.14.7.1. Only the name pattern was wrong. Names now go
to the version parser, and what does not parse as a version is skipped,
which drops the _History companions by the same rule instead of relying
on the digit class to exclude them.

This was live, not hypothetical. WinPythondot-64bit-3.9.0.0b1.md has been
invisible for years, so 3.9.0.0 was diffed against 3.8.10.0 and reported
the beta's changes a second time. Nothing else in changelogs/ answers
differently.

copy_changelogs had the same pattern, and now selects on the parsed
version, so a level travels with its cycle and 3.1 cannot pick up 3.15.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MBk5k7WdpPvx4SUFyEk3U3
@stonebig
stonebig merged commit 35c2fb9 into winpython:master Sep 6, 2026
2 checks passed
@stonebig
stonebig deleted the fix-changelog-release-level branch September 6, 2026 13:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant