Insider build # observations.

Nothing to back this up but...

I'm on the insider fast track in one of my Virtual machines.
For the past months/year, the build #'s are going 19### and stepping about 10-20 digits every 2 weeks or so. 19455, 19468, 19482 etc.

The last build I got June 6 2020 was 19645.
Today I was offered build 20150 dated June 12. I guess MS decided to make the first 2 digits the century, or that's my guess.

Al

Big Al wrote:
Nothing to back this up but...

I'm on the insider fast track in one of my Virtual machines.
For the past months/year, the build #'s are going 19### and stepping
about 10-20 digits every 2 weeks or so. 19455, 19468, 19482 etc.

The last build I got June 6 2020 was 19645.
Today I was offered build 20150 dated June 12. I guess MS decided to
make the first 2 digits the century, or that's my guess.

Al

Since 19041 was released, what you're testing now is
(presumably) "something else".

If you pop the release number in your toaster, there's
likely a suitably worded explanation out there for
what that version corresponds to.

Think of it as a multiplex theater. 19041 was showing in
theater #4. 20150 was showing in theater #5. You've walked
out the door of one of those theaters and are now in
a theater with a different (20H2) movie playing.
Just because 19041 was released, doesn't mean 19645 was
wasted. It could be that a patch 19041.xxx June 2020
was made from 19645 materials.

19041 frozen
- - - - X - - -- - - - - - -- - 19645

- - - - - - - - - - - - - - - - - - - - - - - 20150 - - - - -

Who really knows where that fork happened ?

They have enough staff, just about any arrangement
of streams is possible. Remember that there are
70X as many staff, as are needed to make an OS :-)

Paul

Big Al wrote:

Nothing to back this up but...

I'm on the insider fast track in one of my Virtual machines.
For the past months/year, the build #'s are going 19### and stepping about 10-20 digits every 2 weeks or so. 19455, 19468, 19482 etc.

The last build I got June 6 2020 was 19645.
Today I was offered build 20150 dated June 12. I guess MS decided to make the first 2 digits the century, or that's my guess.

From what I see at:

https://blogs.windows.com/blog/tag/w...sider-program/

there were a bunch of 19xxx builds published in 2020. I didn't bother
to check which were published via the fast versus slow rings or release
preview channel, which they are changing; see:

https://blogs.windows.com/windowsexp...ider-channels/

From what I see at:

https://en.wikipedia.org/wiki/Window...ngs_/_Channels

they've been a year behind on the first 2 digits of the build number
from the last 2 digits of the 4-digit year. This is the first time when
the build number's first 2 digits is the same as the last 2 digits of
the year. Of course, they started with 10xxx for build numbers back in
2015, and they can contrive any scheme they want. You can see a larger
list of build numbers with their release dates at:

https://docs.microsoft.com/en-us/win...er/flight-hub/

VanguardLH wrote:
Big Al wrote:

Nothing to back this up but...

I'm on the insider fast track in one of my Virtual machines.
For the past months/year, the build #'s are going 19### and stepping about 10-20 digits every 2 weeks or so. 19455, 19468, 19482 etc.

The last build I got June 6 2020 was 19645.
Today I was offered build 20150 dated June 12. I guess MS decided to make the first 2 digits the century, or that's my guess.

From what I see at:

https://blogs.windows.com/blog/tag/w...sider-program/

there were a bunch of 19xxx builds published in 2020. I didn't bother
to check which were published via the fast versus slow rings or release
preview channel, which they are changing; see:

https://blogs.windows.com/windowsexp...ider-channels/

From what I see at:

https://en.wikipedia.org/wiki/Window...ngs_/_Channels

they've been a year behind on the first 2 digits of the build number
from the last 2 digits of the 4-digit year. This is the first time when
the build number's first 2 digits is the same as the last 2 digits of
the year. Of course, they started with 10xxx for build numbers back in
2015, and they can contrive any scheme they want. You can see a larger
list of build numbers with their release dates at:

https://docs.microsoft.com/en-us/win...er/flight-hub/

The buildnumber.patchnumber thing is "just for the computers
to track stuff". Since the decision was made to turn Windows
into a rolling release, only the decorative name used for
media reports is the part that matters. Like calling the
next release "20H2", without specifying a month. So it would
be less embarrassing than calling it "2009" and delivering it
in "2011" :-) For some value of "release schedule, what release
schedule?". They may freeze a release with great precision,
but the testing process after freeze seems just a bit
non-deterministic.

Paul

Paul wrote:
VanguardLH wrote:
Big Al wrote:

Nothing to back this up but...

I'm on the insider fast track in one of my Virtual machines.
For the past months/year, the build #'s are going 19### and stepping
about 10-20 digits every 2 weeks or so. 19455, 19468, 19482 etc.

The last build I got June 6 2020 was 19645.
Today I was offered build 20150 dated June 12. I guess MS decided to
make the first 2 digits the century, or that's my guess.

From what I see at:

https://blogs.windows.com/blog/tag/w...sider-program/

there were a bunch of 19xxx builds published in 2020. I didn't bother
to check which were published via the fast versus slow rings or release
preview channel, which they are changing; see:

https://blogs.windows.com/windowsexp...ider-channels/

From what I see at:

https://en.wikipedia.org/wiki/Window...ngs_/_Channels

they've been a year behind on the first 2 digits of the build number
from the last 2 digits of the 4-digit year. This is the first time when
the build number's first 2 digits is the same as the last 2 digits of
the year. Of course, they started with 10xxx for build numbers back in
2015, and they can contrive any scheme they want. You can see a larger
list of build numbers with their release dates at:

https://docs.microsoft.com/en-us/win...er/flight-hub/

The buildnumber.patchnumber thing is "just for the computers
to track stuff". Since the decision was made to turn Windows
into a rolling release, only the decorative name used for
media reports is the part that matters. Like calling the
next release "20H2", without specifying a month. So it would
be less embarrassing than calling it "2009" and delivering it
in "2011" :-) For some value of "release schedule, what release
schedule?". They may freeze a release with great precision,
but the testing process after freeze seems just a bit
non-deterministic.

My guess is they're tagged to the latest released version. Since they've
just pushed out 2004 all subsequent development is based on that codebase
hence the patch numbers rolling over to 20xxxx just recently.

Chris wrote:


My guess is they're tagged to the latest released version. Since they've
just pushed out 2004 all subsequent development is based on that codebase
hence the patch numbers rolling over to 20xxxx just recently.

The build number *continuously* increments from 10240.
Each time they "make world", is a new build number.

Check the build numbers in wiki for the pattern. If you
look at the table, the lead digits are not the year.

https://en.wikipedia.org/wiki/Window...ersion_history

The build numbers are not entirely sequential at the
stream level. I suspect there are gaps, because they're
potentially managing multiple development streams, using
the same build tracking method. But the build number
(stamped inside executables) is part of precision
identifying " *which* shell32.dll we're talking about ".

There was a time, when Microsoft was idiotic enough to
track shell32.dll by *file size*. "Replace the 98,345 byte
shell32.dll file with the 99,789 byte shell32.dll file."
And eventually they became "hungry for version control"
and added a bit more info to each file. They're still
a wee bit careless with the per-file numbering, but you'll
discover how as you vet your files with Properties.
In 18363, you could see a mix of 18362 and 18363 files
as an example. Your guess is as good as mine, as to how
it makes sense to mix files from two build numbers
together. In a sense, this is the same as mixing
Windows 7 and Windows 7 SP1 files together (because
each was tracked by a number in the 9600 vicinity).

In the wsusscn2.cab file (currently 750MB or so),
every file since (perhaps) Windows 2K is tracked in
some way. There is continuity at Microsoft. Huge
continuity. So while I may be tossing these build
numbers around like they don't matter, they do
historically and logically go back quite a ways.
It's like having a spare parts database that still
has a precise part number for a Model T right wingnut.
Even though there are no wingnuts in stock. The identify
of these things lives on. And clogs the file that
tracks them. Microsoft really doesn't want people
downloading that file, which is probably why
MBSA 2.3 was dropped (that's the Baseline Security Analyzer).

They had to make some changes there, because the
scheme they've selected "doesn't scale well".

Paul

On Thu, 18 Jun 2020 02:52:15 -0400, Big Al wrote:

Nothing to back this up but...

I'm on the insider fast track in one of my Virtual machines.
For the past months/year, the build #'s are going 19### and stepping about 10-20 digits every 2 weeks or so. 19455, 19468, 19482 etc.

The last build I got June 6 2020 was 19645.
Today I was offered build 20150 dated June 12. I guess MS decided to make the first 2 digits the century, or that's my guess.

I always read the announcement on the Feedback Hub and the blog, not
that I always understand them, but the Feedback Hub announcement says:
Today we’re releasing Windows 10 Insider Preview Build 20150 to
Windows Insiders in the Dev Channel (Fast ring). Starting with this
build, we are back to releasing builds from the RS_PRERELEASE branch.
Think it means that we are now on the next release version rather than
tidying up the one just released. But I could be wrong.