Purpose of Windows 10 build 10587

[gtgamer468]

Was there a purpose that Microsoft complied a build with the number of the RTM build (10586) plus one? The Collection Book site didn't really have notes about this particular build and I started to become curious about it. Also, why did it have a timebomb like an ordinary beta build?

[Stannieman]

First of all: I really don't know anything for sure, everything I'm writing now is just guesswork.

It could be nothing more than a policy regarding releases.
For example when we at work have the code in our repository always marked as pre-release.
Say we are finishing our 1.1 release we always do it in the following way:
1. Make sure all code that should be in this release is merged and went through the whole QA process.
2. Mark our code as non-pre-release (final)
3. Take this build that came out of CI and keep it somewhere safe, this is what we'll ship.
4. Then IMMEDIATELY bump the version and mark as pre-release again.

Step 4 is to ensure that no new code can be merged and built while still being marked as final. We'd have 2 final builds with same version with different code => not good.
Step 4 naturally causes CI to build the code and that could be what 10587 is.
Now I see that 10587 is still marked as th2, but it could be that this build is nothing more than re-enabling the timebomb and marking it as pre-release.

But again, this is just wild speculation.

[gtgamer468]

That would make total sense. If an RTM build has two different source code, then it can be disastrous as there will be bugs found in one version and then the patching process can create even newer problems. This process ensures that the RTM build will have only one source code. If your guesswork is accurate, then it would all make sense.

[jimmsta]

Nearly every single version of Windows has post-RTM builds that follow up the RTM build. Typically, they're testing something either internally, or they're setting a baseline up for the next progressive branch. Granted, Windows 10 is a rolling release, and they're typically working on a semi-stable and unstable set of forks, those forks are typically out of date with the RTM branch, so they will propagate fixes that were introduced in the last RTM branch into the newer forks. Once they catch-up, they'll create a new build of the new 'slow ring' branch, and continue until they hit RTM on that branch, and the cycle continues.

Speculation - they might be updating the tooling underneath, like the compiler toolchain, dism deployment, any show-stopping dynamic updates for the setup program, etc. It could literally be nothing, or it could be a step-up interim build.