I keep multiple versions of Python installed on Windows, but don’t update them very often. Today, I tried to update 3.9 to the latest release. What I found was the the latest listed releases (3.9.14, 3.9.15 and 3.9.16) all had no links and just a bullet point reading “No files for this release.”
I found and installed 3.9.13 after scrolling down, but I see that a lot of releases are listed as having no file. I can’t help but wonder what that’s all about. What sort of release is it that releases no files? 
Is there a PEP or help page somewhere that explains what “no files” is all about?
That page is for installers, and there are no installers for those versions because they’re in the “security fix” stage, which is source-only. If you follow the “All releases” link instead you’ll find a page with links to the source releases.
Thanks for the information. 
It’s an odd choice for Windows, though, where the vast majority of installations aren’t configured for installation or update from source. 
Not that odd. Windows users are far less likely to stick to old
minor versions of Python and should probably be updating to newer
releases which have installers available. The source-only updates
are more useful to curated software distributions where someone is
continuing to build packages and backport security patches for their
ecosystems (e.g. GNU/Linux distributions and Unix derivatives). This
provides a nice compromise reducing work for the upstream Python
ecosystem in order to provide longer term security support in older
interpreters.
1 Like
Would it be a less-odd choice to simply say “well, that’s it, no more releases on the 3.5.x branch”? I think end users should mostly consider it to be that; once there are no more binaries being released, it’s time to have a really really good think about why you’re sticking to this old version when you could upgrade to a newer Python. The source-only releases are a way to help distributors to stay more-or-less in sync, instead of having everyone backport patches individually, but they’re definitely aimed at the commercially-supported products that incorporate Python.
1 Like
My main reason, fwiw, is that some “competitive programming” sites I use have older releases, and if I develop something offline I want to make sure that it will run when submitted. Not a typical use-case, for sure…
That’s fair; but if you’re running completely offline, you probably don’t need the security patches. So you should be fine taking the last binary release and treating that as if it were the last release at all. As an example, here’s Python 3.6 for Windows:
And here’s something that only those who are releasing downstream (commercially-supported) Pythons need to consider:
In terms of code compatibility, you should have no issues (let’s say that your submitted code actually runs on 3.6.15, but you tested it on 3.6.8 - there’s almost certainly no discrepancies, unless you comb through the patch notes and find something to deliberately mess around with), and the binaries for 3.6.8 will run on every platform that the 3.6 branch was released for.
Hello all,
I also stumbled today that no updated installers are provided for the older branches. I think that’s a shame and not a good decision. Everyone who wants to have e.g. a 3.8.16 installer is forced to build it himself or to use alternative sites like e.g. GitHub - adang1345/PythonWindows: Unofficial Python installers for Windows. This is of course also problematic.
We are currently setting up a terminal server with different Python releases and unfortunately we have the need to install not only 3.11 but also 3.9 and 3.8. So it would have been good if there was an installer for 3.8.16.
How much effort is it for you to update the installers? Can’t it be handled that updated installers for older branches are released when they are security relevant? So as a compromise ?
Regards,
Sascha
The security releases for older CPython interpreters are provided
for use by distributors who are building their own binaries. If
you’re not getting your Python interpreters from a downstream
distributor such as an LTS GNU/Linux distribution, it’s expected
that you’ll just use newer CPython interpreter for which there are
installable binaries provided. The only vulnerability is in the
decision to use older interpreter versions without obtaining them
through a downstream distributor who will take care of patching and
building them for you.
1 Like
there is no one to take care of Windows software if the manufacturer does not do it, thatswhy i am asking here
Who are you considering to be “the manufacturer” in this case? The
volunteers who build the current Python installer binaries in their
free time, or someone else?
Keep in mind that the current source-only releases were added for
use by downstream distributors since the community didn’t have time
to produce binary releases of all those. The alternative was to
simply not release those versions at all, so you would still have
needed to upgrade. It sounds like you’re proposing that they should
“just” (somehow) find the time and resources to make those
additional binary releases for you, unless I’m misunderstanding your
point.
Yes it would be nice for users if open source communities had all
the available resources and interest to just maintain security fixes
for every version they ever made since the beginning of time and
published easy-to-consume installers of them all for every available
platform someone might use, but those limitless resources don’t
exist so someone has to draw a line somewhere. The CPython community
has drawn that line at making binary release updates of each minor
version for approximately two years, after which point lower effort
source-only releases continue for an additional three years.
A new minor version of CPython comes out roughly every year, giving
you about a year to upgrade to the next minor release before the one
you’re on stops getting binary point releases. That’s already a lot,
and I for one am very thankful the community has the collective time
and energy to make that possible. If you need to continue using
older versions of CPython than that, you might want to consider
looking into long term stable distributions which backport fixes and
produce binary builds of those versions for users with that need,
but such a burden shouldn’t be placed on volunteers in the upstream
developer community.
1 Like
For the vast majority of users, it’s safe to just ignore the security-only releases. That means that, for most people, 3.8.10 should be considered the last release of the 3.8 branch. Is that too old? Then it’s time to move up to 3.9 or 3.11.
Why do you need to install 3.8, and why is 3.8.10 insufficient? Start by answering those questions, as the answers will define the best way to move forward.
If I install something new somewhere - like here with the new terminal servers - then of course I take the latest available version.
We (as the IT department) have received feedback from Python users that they can no longer do something with version 3.11.x that they were able to do with version 3.8.x. It seems that there are package dependencies, whether they are real or just seem to be I don’t know.
Maybe it says in a configuration file only works up to version 3.10 and that’s why it doesn’t work with 3.11 but that’s beyond my knowledge.
On your website you write that version 3.8 has support until 10/2024, in my opinion support should also include updated installers.
Apparently there is a need for updated installers otherwise there would not be this alternative site to download installers from. It can’t be in your interest that there are not official installers offered and I think it’s a pity if you then say, well then build your own installer. First, not everyone has the opportunity to do so and secondly, there are of course errors and problems possible. The effort for you is unique, but if everyone should do it yourself then everyone has the effort, so the total effort is much higher.
I do not know if we would be affected by the problems in the version 3.8.11 to 3.8.15 or whether they are only theoretical nature but I do not understand your approach here. And yes, I have read the release schedule web page but I still don’t understand your intention.
I know you won’t change your approach because of me so a final question:
Is it safe at this point to install version 3.8.10 and publish the terminal server it so that developers can log in and build code with it?