Change log does not seem to correspond Version 16.7.0 Preview 1.0

[AlexGuteniev]

Today got Version 16.7.0 Preview 1.0,

I see some of changes marked in changelog as 16.7 isn't there.

Example

Cached the result of QueryPerformanceFrequency in calls to steady_clock::now(), and avoided one division. #646 #653

646 is there, 653 isn't

[StephanTLavavej]

As you've discovered, our release process is deeply pipelined with a surprising amount of latency. The introduction doesn't mention this, although it does say:

This Changelog doesn't attempt to track whether changes shipped in VS 2019 16.x Preview Y versus Preview Z.

While VS 2019 16.7 Preview 1 was just released publicly, it captured microsoft/STL (and MSVC compiler) changes from many weeks ago - I'd have to do archaeology to figure out exactly when, but it's something like a month, maybe up to two. When we merge PRs on GitHub, we simultaneously commit them to the Microsoft-internal MSVC repo where STL and compiler front-end development happens (this branch is named prod/fe). While there's no latency there, there's a long process for changes in prod/fe to ship in VS. (Currently, prod/fe merges to master, meeting up with compiler back-end changes, then MSVC master is periodically used to create release branches for further stabilization, and then those branches undergo "toolset insertion" into the VS repo which is separate from the toolset repo, then that branches for internal Preview, which is stabilized until it can ship publicly. I think I got most of that right.)

All of this stabilizing and release branching means that VS Previews are usually high-quality, even if we go around saying that you shouldn't use them for production use. But this also adds a lot of latency to when changes appear.

In this case, last weekend was the cutoff for MSVC toolset feature changes to ship in VS 2019 16.7 Preview 3 (which will ship at some point in the future; can't say when). From this point forward, we can manually request bugfixes to be ported to 16.7 before production release, but with extra process, and no features (unless very special circumstances apply). STL changes stopped flowing into VS 2019 16.7 Preview 2 ages (weeks) ago, even though it isn't publicly available yet.

Because we rely on exhaustive code review and our code is highly amenable to unit testing (in the sense that it is more possible to thoroughly test every aspect of a library feature than a compiler feature, much less other parts of the whole product), we're able to keep the STL at production quality all the time, with very few regressions. So we rarely benefit from all of the stabilization time, we just experience the latency. (Occasionally we do discover that we broke something badly, and we can fix it before shipping, so it's not all downside.)

But that's why we're on GitHub - so you can immediately build and use the code here! 😸

Returning to the Changelog - now that we've developed a system for consistently updating it whenever we merge a PR, it should be possible to record changes with Preview granularity, not just an entire update. (Previously, when we batched up PRs to write them up, it was difficult to figure out when they got into a particular Preview - but if we write them up as we go, we know when the Preview 1/2/3 cutoffs are.) Although it wouldn't be extra work for us now, I was somewhat concerned that fragmenting the Changelog into separate Previews would be distracting - but I suppose we could simply consolidate sub-sections when an update like VS 2019 16.6 ships for production use (at which point the Preview timeline becomes of historical interest only). I'll go ahead and make that change right now, since we're collecting 16.8 Preview 1 changes now. (Doing this retroactively for 16.7 would take a fair amount of work so I'll have to plead laziness/busy-ness there.) Thanks!