Update using/windows to state that 3.12 supports Windows 10 and newer, not 8.1.

[gpshead]

Documentation

Our (main branch using-python-on-windows docs)

Currently states "This means that Python 3.12 supports Windows 8.1 and newer. If you require Windows 7 support, please install Python 3.8."

I believe this is just a leftover claim from 3.11 given what we say in https://peps.python.org/pep-0011/#microsoft-windows and https://learn.microsoft.com/en-us/lifecycle/products/windows-81 as the Microsoft Extended Support end date is January 2023, 9 months before 3.12 will be released.

We probably want that to say "3.12 supports Windows 10 and newer. If you require Windows 8.1 support, please install Python 3.11" ?

Clarification from the Windows folks would be good here.

[eryksun]

Python 3.12 won't support Windows 8.1 according to the support policy in PEP 11, which states that a "new feature release X.Y.0 will support all Windows versions whose extended support phase has not yet expired". Extended support for Windows 8.1 ends on 2023-01-10. Python 3.12 is scheduled for release on 2023-10-02.

Note that extended support for Server 2012 R2 ends on 2023-10-10, just past the planned release date of Python 3.12. There is no benefit in terms of unconditionally adopting new features from Windows 10 if Server 2012 R2 (6.3.9600) has to be supported. Maybe the planned release date of 3.12 should be delayed a bit to sync this up.

[zooba]

There's a 21/31 chance that we'll release 3.12 after the end of 2012 R2 extended support 😉

I vote we just fudge the dates and say that 2012 R2 will go at the same time. We normally refer to consumer releases anyway, and let Server users infer from that.

[CAM-Gerlach]

For the benefit of others reading this issue, see #76773 and its linked PRs for how this was handled for Windows Vista-8.0

Some points of note:

• There is apparently no longer a working 8.1 buildbot; however, the latest main branch still builds, runs and the test suite passes (minus a few unrelated transient, environment-specific and defective-test failures) as of today on my Windows 8.1 Pro x64 test machine.
• It makes sense to drop support for 8.1 and 2012 at the same time, either in 3.12 or 3.13, since there would be little benefit in dropping the former without the latter.
• Windows 8.1 never had the uptake that Win 7 or Win 10 did, especially by the larger institutional users that tend to have slower upgrade cycles (not sure about 2012 server, though), and usage share as a percentage of total Windows versions is around 3%. ¹
• When dropping 8.1, it seems worth also thinking about whether support for EoL Windows 10 versions should be dropped too, at least those earlier than Windows Server 2016 (i.e. Windows 10 1607), the earliest still-supported mainstream version of Windows 10/Windows Server, which seems to strike a reasonable balance between tying support to consumer or even enterprise Win 10 GAC EoLs ², and supporting all the way back to the earliest Win 10 LTSC release (1507) ³.

Our (main branch using-python-on-windows docs) currently states "This means that Python 3.12 supports Windows 8.1 and newer. If you require Windows 7 support, please install Python 3.8." I believe this is just a leftover claim from 3.11

More specifically, the current docs version is automatically injected here, so this will just continue to state the currently supported version until a decision to drop support for it is made and implemented, presumably on this issue.

Python 3.12 won't support Windows 8.1 according to the support policy in PEP 11, which states that a "new feature release X.Y.0 will support all Windows versions whose extended support phase has not yet expired".

Just to note, PEP 11 doesn't actually say that new feature releases will only support non-EoL Windows versions or that EoL Windows versions must not be supported in new feature releases; rather, it only requires that non-EoL Windows versions be supported.

Footnotes

1. Full disclosure: I do have a personal interest in retaining 8.1 support through at least the initial 3.12 development cycle, because one of my main Windows dev machines is still on Windows 8.1, and I only plan to complete the migration to Win10 (which will require switching to a full clean Win10 installation I've installed in parallel to the original) once the the EoL occurs (i.e. on or about the first missing Patch Tuesday), due to the time and disruption that setting up and migrating everything properly will cost for little to no meaningful benefits to my workflow and a further downgrade in user interface, experience and control/customizability to mobile-OS standards. However, I figure my situation is fairly unusual; most folks in my shoes are likely either still on Windows 7 (as I would be, if not for the security and compatibility issues), bitten the bullet and upgraded to Win 10, or switched entirely to Linux (whereas I still need to retain a Windows machine for some key research, etc. software that won't work on Wine, and a few other things). ↩

2. Tying support to the home or even enterprise GAC EoLs seems problematic at best, as due to the 1.5 year consumer support cycle, the latest available version at the start of development will be EoL before that feature version of Python is released, and even with the 2.5-year Enterprise timeline, the earliest supported release could still be later than any release of Windows Server, leaving server users unable to install the latest version of Python. ↩

3. As LTSC is only intended for, and generally mostly only used by, embedded, IoT, safety/mission-critical and similar deployments, which would be unlikely to need or want an upgrade to the latest Python feature release. ↩