News Stay informed about the latest enterprise technology news and product updates.

Simple Versioning Numbers in Win10 Presage Deployment Changes

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:]
  • 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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This is consistent with the industry's pretty hard shift away from waterfall methodologies to Agile.  While release magnitude will certainly be less, the test and vetting processes have long been a critical component for many companies--especially in light of growing security complexity that results from network virtualization technologies. While Agile may make it quick to advance software company competitive desires and customer feature requests, it will be interesting to see if corporate customers will embrace this type of rapid OS evolution or if they will ask to bring the pendulum back some.
Good analysis, Ron: you raise the very questions to which I alluded in my blog post -- namely, will enterprises with their own formal methodologies for slipstreaming updates and patches into production be able to accommodate this new model as it stands, or will they need additional time to bring into their current slipstreaming activities? Only time will tell, but I think you and I both believe that some compromises will prove necessary.
Thanks for this insight, Ed. Good to know. In most cases, I actually like that you won't have to go back to a baseline version of Windows - can save a lot of time that way. But, like you said, it could end up creating compatibility headaches if you need to stay on a specific build. I wonder if there's an easy way to keep those specific build versions aside in the event you need them in the future? Makes me long for the simpler days of Windows CDs...and floppy disks. :-)

Thanks for weighing in, Kevin. Should you hear any opinions or plans from your industry contacts on this subject, please share them with me here or by e-mail through my website at Thanks!