If you take a look at the Winver information from the latest Fast Ring build for Windows Insiders, aka Build 10586, you’ll see some additional information in the second line of text therein, just below Microsoft Windows:
Whereas old Win10 simply shows “Version 10.0 (Build 10240)” in this position, new Win10 includes “Version 1511”
As it happens, there’s some method to this apparent madness, and I came across this information thanks to an illuminating pair of blog posts from Paul Thurrott (“Windows 10 Fall Update is Set for November Release” 10/21/15 and “Here’s What’s New in the Windows 10 Fall Update” 11/8/2015).
The 1511 that comprises the Version number represents a release in 2015 (the first two digits of the version number), and the 11 represents the month of November, so that one can decode this number as “Windows 10 release for November 2015.” For those interested in applying this nomenclature to the initial release of Windows 10 on July 29, 2015 for Build 10240, that means its version number is 1507 (July 2015, in other terms) even though it lacks that designation explicitly.
But there are some other interesting implications that should be gleaned from this information as well:
- Going forward, Release 1511 becomes the official baseline for Windows 10. That means MSDN will make this version available to those who wish to download and install Windows 10, and that the Media Creation Tool that Microsoft makes available to “Download Windows 10,” will supply that version as well. [Link: https://www.microsoft.com/en-us/software-download/windows10]
- 1511 will remain the current version until the next official release comes out, which Thurrott speculates — a speculation with which I concur, FWIW — will occur on a quarterly to semi-annual basis. (Even though he says “biannual” which means every two years, I’m pretty sure he really meant to set a six-month upper bound on such update frequencies).
- Restore and repair activities will default to the latest current build for Windows 10, whatever that may be. That obviates the need to install an original release and then to apply multiple waves of updates to “catch up” with current updates and fixes. This should work well for consumer-grade users, but I find myself wondering what this means to enterprises and business-class users. Will they be able to keep up with the frequency of official versions and be able to apply the vetting and testing that goes along with their adoption and use in production environments? Will they have the option of trailing behind by a release, to add some slack into the system to give them time for testing and vetting? This will be an extremely interesting question to see answered in everyday practice.
But indeed, it looks like the old Windows paradigm of a major new release, punctuated by Service Pack like addenda at annual intervals, is about to change into something new and different. Time will tell if this model works better or worse than the old regime, and if enterprise/business-class users will be able to mold it to fit their deployment and maintenance models.