GeezerVison is showing github.com — Docs: tarfile.LinkFallbackError versionadded says 3.15, but it ships in 3.14.0 and 3.9.23+ · Issue #159013 · python/cpython
Docs: tarfile.LinkFallbackError versionadded says 3.15, but it ships in 3.14.0 and 3.9.23+ #159013DescriptionDocumentation
Doc/library/tarfile.rst:
.. exception:: LinkFallbackError
...
.. versionadded:: 3.15
But the exception came with the gh-135034 security fix (CVE-2025-4517 and
related). It is listed in Doc/whatsnew/3.14.rst and exists in 3.14.0. It was
also backported to security releases of older branches:
$ python3.14 -c "import tarfile; print(tarfile.LinkFallbackError)"
<class 'tarfile.LinkFallbackError'>
$ python3.13 -c "import tarfile; print(tarfile.LinkFallbackError)"
<class 'tarfile.LinkFallbackError'> Suggested fix: use versionadded:: 3.14, ideally with a note that it was
added in 3.9.23, 3.10.18, 3.11.13, 3.12.11 and 3.13.4 as part of the security
fix. That matches how the extraction filters document their 3.8.17+ backports.
Linked PRs
Activityhugovk commented on Oct 8, 2026 ArtVsMark commented on Oct 8, 2026 Thanks — you're right that each branch documents its own backport, and those look correct: 3.14 says 3.14, 3.13 says 3.13.4, 3.12 says 3.12.11 and so on.
The problem is only in the main and 3.15 branches. There Doc/library/tarfile.rst has .. versionadded:: 3.15, so the 3.15 docs will say "Added in version 3.15". But the class already ships in 3.14.0, and the 3.14 docs say 3.14, so a reader of the 3.15 docs gets a newer version than the real one. I think main and 3.15 should say 3.14, the same as the 3.14 branch.
Minor, and probably won't-fix since 3.9 is EOL: on the 3.9 branch the directive is still .. versionadded:: next, which was never replaced with 3.9.23. StanFromIreland commented on Oct 8, 2026
Minor, and probably won't-fix since 3.9 is EOL: on the 3.9 branch the directive is still .. versionadded:: next, which was never replaced with 3.9.23.
Yes, we can't fix that, but that seems like a possible bug in the release process (CC Hugo)? hugovk commented on Oct 8, 2026 Hard to say, that 3.9 release was over a year ago (and not by me). On the bright side, I don't see any other orphan nexts in the current branches.
But I think this highlights a process bug, we need to be careful backporting next because it has different meanings per branch.
For example, next going:
- into 3.13 (bugfix) becomes
3.13.17
- into 3.14 (bugfix) becomes
3.14.9
- into 3.15 (RC prerelease) becomes
3.15
- into
main (3.16, unreleased) becomes 3.16
Those first three are fine, it's the last which is misleading?
This problem goes away when I release 3.15.0 tomorrow, because after that we resolve as 3.15.1 instead of 3.15.
But it will resurface next year when main becomes 3.17 and we make a new 3.16 branch. It happens during the feature freeze window.
I think we want to avoid resolving more than one x.y in different branches. Multiple x.y.z are fine.
The rule is: next means "the next release of this branch", and should only ever resolve to a bare x.y on one branch. If backporting next during the feature freeze window, then next can be backported to older branches, but the next in main should become the first x.y branch.
I expect this has happened to more than just LinkFallbackError during the 3.15 feature freeze, and there's more to clean up. ArtVsMark commented on Oct 9, 2026 Following up on "there's more to clean up": I scanned Doc/ on main for every .. versionadded:: 3.15 attached to an object (131 of them) and checked whether that object already exists in 3.14.8 and 3.13.14. After discarding false positives (new parameters, CLI options), one more case of the same backported-next pattern turned up, from the same gh-135034 security fix:
os.path.ALLOW_MISSING — Doc/library/os.path.rst on main has .. versionadded:: 3.15 on the data entry, and the realpath() note says .. versionchanged:: 3.15 "The ALL_BUT_LAST and ALLOW_MISSING values for the strict parameter was added". On the 3.14 branch that note is versionchanged:: 3.14, on 3.13 it's 3.13.4. ALL_BUT_LAST is genuinely new in 3.15; ALLOW_MISSING is not.
Suggested fix: ALLOW_MISSING → versionadded:: 3.14 (as in #159040), and split the realpath() note so only ALL_BUT_LAST is listed under 3.15 (also "was" → "were").
This only covers versionadded on objects; versionchanged notes for backported behaviour changes weren't checked systematically.
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|