14251 builds, sitting in a tree

Kay Eye Ess Ess Eye En… wait a minute…

A shitstorm is about to hit the Windows community. Reason? The build jump made earlier this week from build 11107 to 14251. And it’s not because of that, but more the reason the Windows community is trying to paste onto it. So, let me explain what’s wrong with the reasoning a lot are applying to this build, and how this kind of things actually work. Let’s start with some history.

Build numbers have been part of Windows for a long time. With Windows Vista, Microsoft added a couple of rules to these build numbers to streamline the way they are assigned.

  • As always, build number can’t go down, and neither can they be reused. *
  • The final release should have a number that can be divided by 16. Many claimed that the actual rule was a number that can be divided by 400, but that isn’t true. Windows Vista, 7, 8 and 8.1 did indeed all have numbers that could be divided like that, but it never was a rule.

This was mainly in place so that Microsoft could easily assign updates a new number. The builds of a final release had to be dividable by 16 because that way, the last 4 bits could be used to indicate updates, for example, a Service Pack. Service Packs always bumped the build number by 1.

With Threshold 2, the Windows 10 November Update, Microsoft dropped that second rule, no longer did final builds need to be dividable by 16. By the way, the original version of Windows 10, build 10240, also went against the 400-”rule”.

* One thing has to be said though. After a build jump, 2 build-ranges can be used simultaneously. For example, after build 9926, Microsoft jumped ahead to 10000, however build 9927–9942 where also compiled after that. A similar example is the jump from 10068 to 10100, while build 10069 up to 10081 where also compiled.

Build jumps
Build jumps are nothing new. We’ve seen them before, and we’ll see them in the future quiet 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 decided to jump to a higher build. For example, this happened after the 3rd 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 10586 to 11040.
  • 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 that reason.
  • And other reasons.

What’s going “wrong”
And it’s that 4th reason that all the drama is about. And the problem is, people see build numbers as version numbers. And that’s wrong. A build number is not a version number. The size of a build number is not an indication of the amount of changes. What’s more important is the number of builds in between (but that, once again, doesn’t indicate anything, as this depends on the development phase too). It’s quiet a misconception.

But many people are now expecting a huge feature-drop when the first 1425x build drops. And that’s going to make for a lot of disappointment, solely because a lot of people don’t understand a versioning system. So, basically, build 11106 to 11107 could very well be a larger update than 11107 to 14251 is.

So that’s that, the new build jump is solely to sync the versions of Windows. The coming builds are probably going to contain more and more features compared to the previous builds, but don’t expect any huge changes just because of a number.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.