Projectreunion: Make official Windows versions and build versions relatable

[stevenbrix]

There are 3 different possible names each Windows release has: the codename (RS4), version number (1803), and build number (17134). Since the official version number and build number have no correlation, there is no logical way to connect the two, and it makes communication very challenging. Most people I talk to, including myself, always have to look online to double check.

I can't count the number of times someone tries to mention a Windows build and it becomes so difficult..."that was introduced in RS4...which version is that...err 17134? Well what's the public name for it, I think that was 1809...?". Wrong, it was 1803! The "1809" is helpful, because you then have an idea of when it was released (2 months later in November), but it isn't helpful to the public or average users because they don't know or care about why we version our software this way.

Below are some tables and information for the current scheme and a proposed scheme.

Current scheme

Windows 10 version scheme: YYMM
Windows 10 build scheme: ABCDE
Windows 10 insider SDK scheme: 10.0.ABCDE.0
Windows 10 official SDK scheme: 10.0.ABCDE.0

Windows 10 Version | Windows 10 Build | Windows 10 SDK | Date of Availability
-- | -- | -- | --
1909 | 18363 | 10.0.18363.0 | Nov 12th 2019
1903 | 18362 | 10.0.18362.0 | May 21st 2019
1809 | 17763 | 10.0.17763.0 | November 13, 2018
1803 | 17134 | 10.0.17134.0 | April 30, 2018

Proposed scheme

If you make the build numbers match the date itself, then you always have an increasing number and you can easily correlate builds to windows versions and the date they were released.

Windows 10 version scheme: 10.N
Windows 10 build scheme: YYMMDD
Windows 10 insider SDK scheme: 10.N.YYMMDD
Windows 10 official SDK scheme: 10.N

Example, for today's build, 6/13/2020, the build would be: Windows 10.1.200613

Then, once Windows 10.1 ships, we move onto Windows 10.2, and the cycle repeats and it's very nice and easy.

Assuming we had started this scheme back in RS4, this is what the previous table would look like:

Windows 10 Version | Windows 10 Build | Windows 10 SDK | Date of Availability
-- | -- | -- | --
10.4 | 190914* | 10.4 | Nov 12th 2019
10.3 | 190302* | 10.3 | May 21st 2019
10.2 | 180909* | 10.2 | November 13, 2018
10.1 | 180315* | 10.1 | April 30, 2018

*I don't know the actual dates of the month the build snapped, so the last two numbers are just made up.

There are many benefits to a scheme like this:

• Easy to distinguish Preview SDK's from official ones by the numbering scheme (10.N vs 10.N.YYMMDD)
• Having a simpler version number puts less cognitive load on having to remember numbers, you really only have to remember the number following "10.".
• The versions being linear makes it much easier to know that 10.5 follows 10.4. You have to make the connection yourself that 2004 follows 1909.
• All versions are relatable
• Windows SDK version numbers are prettier ♥
• This is the industry standard for how software is versioned, all other operating systems our users use follow this scheme.

[mdtauk]

Ideally the Windows Team now it is in the hands of the Windows Server/Core team, could come up with a simple and clear naming scheme. Something programatic and understandable for Marketing/Communications and Users.

Months and Dates are not as helpful as you may expect - especially with phased slow releases, and gaps between a build going _gold_ and the day and date you receive it on your device.

As for how this relates to ProjectReunion, the releases will be out of sync with the OS version releases. So whilst it will aid in informing developers which versions are currently supported - the Reunion versioning needs to make sense with the out of sync releases.

[stevenbrix]

Something programatic and understandable for Marketing/Communications and Users.

Yup, that's exactly what I'm talking about.

Months and Dates are not as helpful as you may expect - especially with phased slow releases, and gaps between a build going gold and the day and date you receive it on your device.

Yeah, I don't think they're helpful at all for end users. As someone who has worked on the Windows platform, I find them somewhat helpful.

As for how this relates to ProjectReunion, the releases will be out of sync with the OS version releases. So whilst it will aid in informing developers which versions are currently supported - the Reunion versioning needs to make sense with the out of sync releases.

That's a very fair point, although I wasn't trying to refer to ProjectReunion versioning. I don't know what's really happening with the Windows SDK now. Before, the SDK was comprised of APIs, build tools, debuggers, profiling tools, and I'm sure much more. The APIs and build tools are being moved out and shipped as Nuget packages for Reunion, but I don't know what will come of the other tools. Perhaps installable via winget? 😎

It's pretty early on, so I'm sure this is still being worked out at this point.

I just posted this issue here because I know a lot of people viewing this GitHub would be the appropriate people to make any sort of change here, and there's no other good way to provide this feedback on an open forum otherwise.

[maxkatz6]

Also when we use ApiInformation.IsApiContractPresent I always need to google which major version of contract specific Win version has.
Seems it already matches windows release number: https://docs.microsoft.com/en-us/uwp/extension-sdks/windows-universal-sdk

Seems like related: https://github.com/MicrosoftDocs/winrt-related/issues/103

[jonwis]

Would a set of named constants help? Or a IsWindowsAtLeast(...)? See also the version helpers which let you ask this question based on version.

@maxkatz6 :

Also when we use ApiInformation.IsApiContractPresent I always need to google which major version of contract specific Win version has.

Can you help me understand when you choose "is contract present" vs "is member present" versions of API queries? You'll have better luck using the "is specific member/type/class present" checks than "are you Windows 10.0.18362.0 or better?" in many ways.

[maxkatz6]

@jonwis
I agree that "is member present" should be preferable method.
But I often can see not mine code that use IsApiContractPresent method.
Usually the reason could be to reuse result between all API per specific contract (I not sure if there is a reason to cache it tho).

[stevenbrix]

I just came across this, the Windows store refers to Windows version numbers by their build numbers:

When the settings app refers to the Windows version differently (as described in this issue):

This is clearly a bug on the Store app and it's definitely a fit-n-finish issue. I doubt most people ever look at this or are confused by it.

[Jaiganeshkumaran]

Unlike the version number of Windows 10, the build number has real significance. In most apps and software the build number will be reset to 0 when the major and minor version increases. That's not the case with Windows. For the version number, notice that they are spaces in between. This is because currently the version number is based on RTM year and month although they have started to use the H1 and H2 suffix recently. The build number also seems to have spaces in between but technically not since they only release a few builds to the Insider Preview and most of them are internal. Actually the build number is incremented for every build of Windows. Technically the build number means the compilation time. For example, the latest insider preview has a build number of 20170 which means it's the 20170 compilation of Windows. This isn't really useful but it's good to know.

[stevenbrix]

. For example, the latest insider preview has a build number of 20170 which means it's the 20170 compilation of Windows. This isn't really useful but it's good to know.

@Jaiganeshkumaran yeah, I think that's fine thing to continue carrying forward. In my example I was using dates, but we can use that number instead:

10.1-insider.20170

Then we ship windows 10.1, and you drop the "-insider" preview suffix and we just have "10.1".

Or we could be like Android and have 3 versions:

10.1.0-insider.20170

@stevewri is this something we would consider doing?

[tringi]

I need to chime in just to agree. Stopping incrementing minor version number with each release was not the brightest marketing idea, to say it lightly.

But the YYMMDD might not be ideal. That number is unsigned 16-bit integer, implemented as such in dozens of components across the system, and year 2065 is not that far now.

[Jaiganeshkumaran]

@tringi The major and minor numbers can be changed because most apps only check the build so it's shouldn't be changed to prevent compatibility issues.