fix(versioning/pep440): drop the local segment from a compatible release

[MLuc24]

Changes

~= updates were abandoned when the new version carried a local segment. From the issue:

currentValue: "~=38.0.0"
newVersion:   "38.3.3.post1+git.5af13757"
result:       "~=38.3.3.post1+git.5af13757"
msg:          "pep440: failed to calculate newValue"

A local version segment is not valid in a compatible release specifier, so that range matches nothing. getNewValue builds the range, fails its own satisfies() check at the end, logs the warning and returns null, and the dependency is never updated.

The ~= branch only reached this when the current value and the new version have the same number of release components, which is why the failure looks narrow:

current	new version	before	after
~=38.0.0	38.3.3.post1+git.5af13757	null	~=38.3.3.post1
~=38.0.0	38.3.3+local.1	null	~=38.3.3
~=38.0.0	38.3.3.post1	~=38.3.3.post1	unchanged
~=38.0	38.3.3.post1+git.5af13757	~=38.0	unchanged

Only the local segment is dropped. A post release is valid in ~= and stays, which keeps this consistent with what the same input already produced without the +… part.

I checked the other operators before settling on this scope: >=, <, and combined ranges already return the current value untouched when it still matches, and ==38.0.0 correctly keeps the local segment, since == is one of the two operators that permit it. So the defect really is limited to ~=.

One note for a maintainer: the issue says the expected result is ~=38.3.0. This PR produces ~=38.3.3.post1 instead, because that is what ~=38.0.0 already produces for 38.3.3.post1 today — matching existing behaviour seemed better than changing the precision rule as part of a bug fix. Happy to switch if you would rather it truncate.

Context

• This closes an existing Issue, Closes: pep440: failed to calculate newValue for ranges with complicated newVersion suffixes #33816

AI assistance disclosure

• Yes — substantive assistance (AI-generated non-trivial portions of code, tests, or documentation).

The diagnosis, the fix, the test and this description were produced by Claude Opus 5 running in Claude Code. The before/after values in the table were printed by calling getNewValue on main and on this branch, not inferred.

Use of AI in replying to PR comments

Who answers review comments:

• Nobody has explicitly committed to replying.

Answering honestly per the template: @MLuc24 owns this account and directs the work, but has not committed to replying to review comments. If a maintainer asks for changes and nobody responds within a reasonable window, please close this rather than leave it open.

Documentation (please check one with an [x])

• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Newly added/modified unit tests

Added to lib/modules/versioning/pep440/range.spec.ts rather than the it.each table in index.spec.ts, because the long fixture values there force Prettier to realign every row of that table and bury the change in noise.

• vitest run lib/modules/versioning/pep440/ — 239 passed
• The new test fails on main and passes here:

  BEFORE: Tests  1 failed | 6 passed (7)
  AFTER:  Tests  7 passed (7)
  

• tsc --noEmit -p tsconfig.json — clean
• oxlint, biome check, prettier --check on the changed module — clean

I did not run Renovate against a real repository, so the end-to-end update is unverified.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.