platform.release() returns platform.uname().release, which comes from platform.win32_ver() in Windows [1]. The issue with Windows 11 is being discussed in bpo-45382, but no PR has been submitted yet to resolve the issue.

> >>> sys.getwindowsversion().platform_version
> (10, 0, 22000)

This result is correct [2], but you should use platform.version() instead. The major.minor version of Windows 11 is 10.0. The build number for Windows 11 is 22000 and above. The latest build number for Windows 10, in contrast, is 19044.

The system version number concerns API compatibility, not user-interface updates or marketing names. Windows XP, XP Professional x64 Edition, Vista, 7, 8, and 8.1 correspond respectively to Windows system versions 5.1, 5.2, 6.0, 6.1, 6.2, and 6.3. System versions 7.x, 8.x, and 9.x were skipped. Version 10.0 is the first system version with two client workstation releases, Windows 10 and Windows 11. It's thus the first time that the build number is required to differentiate the release name.

The `platform_version` attribute of the sys.getwindowsversion() result is supposed to be the true OS version in case the API is using a compatibility-mode version. It's based on the product version of the system file "kernel32.dll". However, it turns out that this is also not reliably the true OS version. The sys documentation was updated with a note that suggests using the platform module instead [3].

---

[1] https://docs.python.org/3/library/platform.html#platform.win32_ver
[2] https://en.wikipedia.org/wiki/Windows_11_version_history#Version_history
[3] https://docs.python.org/3/library/sys.html#sys.getwindowsversion