Python 3.5.9 corrects a cached release archive

A release can need a new version even when the intended program has not changed. Python 3.5.9 addresses a distribution problem in which some users downloaded a prerelease archive under the expected release location. The correction concerns which source reached those users, so understanding it requires looking beyond the version's apparent place in a sequence of maintenance updates.

The release page explains that a CDN caching problem affected the Python 3.5.8 XZ source tarball. Some users received a prerelease copy. It says that 3.5.9 contains no new changes and is identical to the proper 3.5.8 release apart from the version number.

The tagged changelog dates the release to November 1, 2019 and states the same reason for it. That makes this a release-identity correction. Describing it as a new set of interpreter fixes would mislead a reader about what changed and why the new artifact exists.

I find this distinction relevant to Python's operational complexity. Knowing the language version is useful, but it is not the whole explanation of how an executable came to exist. The source artifact and the process that delivered it are also part of understanding the runtime an application depends on.

Intended contents and delivered contents can differ

The release explanation identifies two different copies associated with 3.5.8. One is the proper final release. The other is a prerelease version of its XZ archive that some users received because of caching. That distinction is the basis for the new version, even though the desired code already existed.

A cache is intended to provide an available copy of requested content. Here, the documented problem is that the copy did not represent the intended final release. The consequence is uncertainty about what a download associated with the earlier release actually contained for a particular user.

The source does not identify every affected user or describe the complete cache configuration. There is no basis to claim that every download was wrong, that all archive formats were affected, or that the incident involved malicious modification. The stated scope is some users downloading the XZ source tarball.

A new version gives the corrected distribution a separate identity. It lets a maintainer request the newly released artifact without treating the contents of an earlier download as settled by its expected release name. That is a practical consequence of the republishing decision, independent of whether a particular application exercised any difference in the prerelease code.

No new changes is an important release fact

The tagged changelog explicitly records no new changes. That rules out an ordinary explanation built around fresh fixes in 3.5.9. It also prevents treating the higher patch number as evidence that another vulnerability has just been repaired.

For a user who already obtained the proper 3.5.8 source, the release says the runtime contents are unchanged apart from the version. For a user who received the prerelease archive, the issue is obtaining the intended final contents. Those are different starting points even though both users may think they downloaded the same earlier release.

This is why a comparison needs a known baseline. Comparing 3.5.9 with the proper final 3.5.8 asks whether the intended source changed. Comparing it with the mistakenly delivered prerelease asks whether the user's actual source matched that intended release. The announcement answers the first question directly and explains why the second question exists.

That distinction also matters to an incident description. A report that says an installation moved to 3.5.9 can name the corrected release identity. It should not infer a new runtime feature or a new security patch solely from that number. The release's purpose supplies the missing interpretation.

Source-only maintenance has a separate build step

Python 3.5.9 is a source-only release on a branch maintained for security fixes. The upstream release therefore supplies source archives, while the executable used by an application may come from a distributor or a local build. A source correction and its arrival in a deployed interpreter are separate events.

For a distributor, the relevant input is the archive actually used in its build process. For a local build, it is the source obtained before compilation. A claim about a release's intended contents does not establish which of those contents a particular process used when its input was affected by the documented delivery problem.

This explanation does not require a new packaging workflow. It requires preserving the distinction between an upstream release declaration and the artifact used to produce an installed program. The CDN incident makes that distinction visible because a familiar release name did not always lead to the expected archive.

I prefer a maintenance explanation that states this directly. The release solves a distribution ambiguity, and the project has chosen a new version to identify the corrected source. That is sufficient reason for a release without inventing additional engineering changes to make it sound more substantial.

A release number can describe delivery work

The version is doing useful coordination work in this case. It distinguishes a newly distributed source release from the earlier location associated with an incorrect cached archive. Its meaning comes from the accompanying explanation, which states both the delivery failure and the absence of new code changes.

Python 3.5.9 consequently needs to be understood through the artifact a maintainer obtained. The proper 3.5.8 release already contains the intended code. The newly numbered source release gives users a separate published artifact after the caching problem, with its equivalence to that proper release recorded in the changelog.