With the Anniversary Update’s final build coming up really soon, many people are out to guess what the “RTM” build will be. I’m using “-signs since the term “RTM” has been dropped for Windows 10 (or at least: they reather not use it in public anymore), so it doesn’t actually apply here. However, many people seem to get the whole idea wrong and are still stuck to the old rules of builds from the days of Windows Vista, even self-claimed “experts” are getting it horribly wrong:
Because not only is “10.1” as kernel version just plain bullshit, the build being 14400 is to. And guess what; so is the delta being 16384. And thus, here is my basic explanation of the Windows versioning system.
But before we can do that, what actually is Windows’ version number? There are a number of options and just for the sake of example, I’m going to take the Windows 10 November Update as a base:
- Windows 10 November Update
- Version 1511
These three can all be used to identify last Novembers release. Generally, the Windows Insider community uses the second one to communicate about new versions since it is the only one that actually always changes for each new release. The first is just the name of the product although also often used to indicate a certain version of Windows (but since Windows is now always “10”, the long title for updates has become kind of annoying to use to identicate versions). The third option is actually new in the November Update, although retroactively used for the original Windows 10 release, too (which is now called version 1507).
I guess you can say that all are equally correct. But the name is becoming irrelevant leaving only the build string and version number. The first one is most often used by Insiders and Microsoft themselves, while the later is used by Microsoft to communicate to the general public.
The name of a Windows version is rather “random”. Microsoft never followed the same pattern for more than 2 versions, except for the first 3 versions which only carried their version number as name. Ever since, we got 95, 98, Me, 2000, XP, Vista, 7, 8, 8.1 and 10.
However, due to Windows 10, even that name has become errelevant to reference to the recent versions of Windows, since they are all called Windows 10. Unless you’re willing to write down the full name of each release. This was actually Microsofts goal: make the name after “Windows” irrelevant.
Since the November Update, Microsoft introduced a new versioning system that labels a version by the date it got released. In this case that was 1511, noted as YYMM where “15” stands for the year 2015 and “11” for the 11th month: November. The original version of Windows 10 got retroactively named 1507 and the coming Anniversary Update is labeled version 1607 (despite being released in August). This is straigth forward, not much explanation required.
The build string
The build string, this is the one it is all about as it is also the only one that is unique for each and every release of Windows, being a preview or final release. Despite its importance, not many people seem to clearly understand how they work, especially some “insiders” on Twitter.
So, to explain this, let’s device the string into a number of sections:
The kernel number
The first 2 numbers in a build string represent the kernel version. While they seem like a major number, their value is more fabricated. Windows Vista bumpt the version to 6.0 and ever since, Microsoft only bumped the minor number. Windows 7 carried version 6.1, Winodws 8, despite the massive change it was, carried version 6.2 and Windows 8.1 carried version 6.3. For the early development of Windows 10 version 6.4 was used and the first Windows 10 builds also launched with that number. After that, Microsft bumped it to version 10.0, it hasn’t changed ever since. WZoR is claiming that Microsoft will bump the kernel to version 10.1 somewhere between now and the compilation of the final build, which – again – is extremely unlikely.
The build number
This is the most important and most used part of the build string. The build number is unique for each and every build, each number can be used exactly once (in each lab). There can be revisions upon that build, but the same number can not be reused (although even revisions sometimes get revisions that do leave the delta and build the same and only change the date-time). This is the only artificial number that is actually bound to rules. And these rules are the following:
- A build number can never go down
- A build number can never be reused (exception: see above)
- The final build must have a number devideable by 16
- The final build must have 16384 as its delta
The last 2 rules where introduced with Windows Vista and where in place to keep some bits free for servicing releases.The 3rd rule here is the reason why the build number of a final release used to be predictable, together with the fact that Microsoft often went for a “fancy number”, and it is this rule that people like WZoR use to “predict” tbat build 14400 will be the Anniversary Update’s final release. There is only 1 minor issue with that:
The last 2 rules don’t apply anymore. With the November Update, Microsoft dropped these rules, hence why the build number could be 10586.0 for the final release. 10586 can’t be divided by 16 and 0 is – obviously – not the same number as 16384. And this claim is also bullshit:
If these rules still existed with the November Update, it would also have to follow them, but it doesn’t. The result of this rule being dropped is that Microsoft doesn’t have to jump anymore, instead, the build that is stable enough, goes out with the number it has, end of story. 10586 is already just a random number and there is no reason for the Anniversary Update to suddenly jump back to old habbits. Likely, it will be somewhere in the 1439x-series, perhaps late 1438x, but that is less likely.
Build jumps are artificial bumps in the build number. We’ve seen them before, and we’ll see them in the future often too. There are multiple reasons why Microsoft would suddenly skip a couple of builds:
- During development of one version, they’ve reached a certain milestone and decide to jump to a higher build. For example, this happened after the 4th Windows Technical Preview, when Microsoft decided to jump from 9926 to 10000.
- At the end of development, a number of builds is being reserved for updates that might require the build number to go up.
- Shortly before the end of development, when Microsoft starts working on the next version of Windows, they skip a range of builds for escrow. An example is the gap between the Anniversary Update and the 148xx-series of builds, used for development of Redstone 2.
- Sync the version number of Windows. An example is the jump from 11107 to 14251.
- When they make a mistake, the build jump from build 8888 to 9200 for Windows 8 is an example for this reason. As explained earlier, Microsoft wanted to use 8888 because it is a fancy number, but after compilation, they realized it couldn’t be divided by 16.
- And other reasons.
Microsoft used to prefer using a number that fitted with the release. Windows 95 for example carried build 950 and Windows 98 had build 1998. Since the 16-rule in Vista, using a fancy number got hareder. You could claim that Windows Vista itself does have a fancy number with build 6000, but Windows 7, 8 and 8.1 do not. Windows 7’s beta did, using build 7000. Microsoft wanted to give Windows 8 build 8888, but after compiling they realized that 8888 can’t be devided by 16. The next best thing was build 8800, but since 8888 is already past that, that number was lost to them, forcing them to something higher, eventually ending up with build 9200.
The lab name
The lab name is where a build originates from. These are often named after the feature they are inteded to develop but there are also some generic labs like “rs1_release” which are mostly used for distribution purpose and/or supposed to collect all features for the other individual branches. If you want an explanation for every (known) lab name, I suggest you go take a look here.
The date-time stamp
The final bit of a build string is rather self explaing. It is just the date and time the build got compiled on in a YYMMDD-HHMM format. For the above mentioned build string (the November Update), that would be 29 October 2015 on 17 o’clock.
Can we predict it?
That begs the question: can we predict the build number of the final release of any future version of Windows 10? The answer is: no. The only thing we can go by is that Microsoft usually goes up 1 a day, except for weekends. But even that isn’t always true as there is always a chance they might do just that, or perform a build jump. So basically, don’t let anyone fool you: it can’t be predicted accurately anymore, these times are over. Microsoft now uses the build they end up with and that’s it.
So anyone telling you that build 14400 is going to be the final Anniversary Update build is just a fool, anyone claiming that the 16-rule is still in place and simply doesn’t apply to the November Update because it is a “minor update” equally so. That’s not to say that 14400 can’t be the final number, because it can, but unless Microsoft is planning to compile for another 15 days worth of builds or does a random build jump, there is no reason to believe this will happen.