Hi,

A step sideways from #11666

Is your feature request related to a problem? Please describe.

Until Version 2004 (May 2020 Update), Windows 10 feature updates were of the form YYMM where YY denotes release year and MM denotes the month the update was finalized. For example, May 2020 Update was finalized in April 2020, hence 2004.

This changed with October 2020 Update. Although Windows Registry will record release Id of 2009, it is publicly shown as 20H2 (second half of 2020). This breaks compatibility with current Windows 10 version check function/map as it doesn't know about the new naming scheme.

Describe the solution you'd like

As noted by @feerrenrut in #11666, rework winVersion.isWin10 function and the related Windows 10 versions dictionary to accept both integers and strings and convert keys into a suitable type (likely str). This will allow developers (and power users) to check for past and future Windows 10 feature update builds. Using a string also makes the version map more flexible in order to prepare for possible changes to the versioning scheme.

Describe alternatives you've considered

Use release Id's to represent Windows 10 feature updates. This means we need to keep track of release Id's to YYHx i.e. 2009 -> 20H2.

Additional context

See #11666 for technical discussion on this issue.

Compatibility:

In the short term, checking for both integers and strings will work for existing code. If keys for Windows 10 version map are to become strings, compatibility notice should be included for a time. Therefore it is proposed that:

1. Accept both integers and strings in 2020.4 or possibly throughout 2021 releases.
2. If version map will use string keys, announce this fact next year and switch to accepting only strings in 2022.

Or if breaking compatibility can be done now:

1. 2020.4 will see isWin10 function accepting both strings and integers.
2. 2021.1 will only accept strings.

The best option would be option 1.

Thanks.