GitHub: Create releases for VS 2019 16.5 and beyond

[StephanTLavavej]

A snapshot of the STL's sources was taken for VS 2019 16.5, the first time that changes from microsoft/STL contributors appeared in Visual Studio. We should create a GitHub release for this historic moment. We need to:

• Verify that the commit that most closely corresponds to...
  • VS 2019 16.5 is b614834.
  • VS 2019 16.6 is 2b2746d.
  • VS 2019 16.7 is 0e4c641.
  • VS 2019 16.8 is be0441c.
  • VS 2019 16.9 is e604b6c.
  • VS 2019 16.10 is 8eca13a.
  • VS 2022 17.0 is a9321cf.
  • VS 2022 17.1 is 3c2fd04.
  • VS 2022 17.2 is 4bb41db.
  • VS 2022 17.3 is 60decd0.
  • VS 2022 17.4 is af8adfa.
  • VS 2022 17.5 is c873cf0.
  • VS 2022 17.6 is 28a6aab.
  • VS 2022 17.7 is a621095.
  • VS 2022 17.8 is ab60075.
  • VS 2022 17.9 is 900eeac.
  • VS 2022 17.10 is d6efe94.
• Choose a naming convention for the tag: vs-2019-16.8.
• Choose a release title: VS 2019 16.8.
• Take release notes from the Changelog.
  • Finish Changelogging VS 2019 16.5.

[BillyONeal]

We don't expect that to be a common sync target, so making the tag verbose sounds fine to me. How about visual_studio_2019_16.5_preview2?

[barcharcraz]

that sounds fine to me as well. Making the tag long like that also decreases the likelihood people will consider that yet another official product version.

[BillyONeal]

Write release notes

I think we should submit a few "big deals" for the VS release notes, then the github releases thing replaces the "STL Features and Fixes" blog posts we did from time to time. Since our PM friends don't seem to like those posts anyway...

[jonwil]

Does this mean it will be possible to pull the tag and compile something that is a functionally identical (and ABI compatible) replacement for the dll that gets shipped with the product? Or are there things (e.g. having to do with XP targeting) that would prevent it?

[barcharcraz]

That is the intent. Currently you should be able to pull this repo and build something functionally identical to the "desktop" flavors.

So yes. that is the intent, and it should be possible. We will likely accept bugs if that's not possible.

The libraries shipped in visual studio are built using the same sources as appear here.

[BillyONeal]

Of course there's only "P" (e.g. msvcp140) components here. vcruntime et al. are still needed for a functional program.

[pmisik]

Hi
If I remember correctly Microsoft provides stripped pdb(s) for msvcp140.dll dlls.
Now, when you are open source, it would be great to see whole call stacks if you can.

Are you considering to distribute pdb files with unstripped debugging info that is linked to stl github repo?

I completely understand it may be quite complicated for you to distribute pdbs indexed with github links form Microsoft “sandboxed” build eco-system.

But I still think it might be helpful to provide us at least tag that could give us ability reindex msvcp*.pdb in internal systems with source code linking to github.

Better call stack crash reports we can repot to you so better STL you can ship.

Thank you

Palo Misik

[BillyONeal]

If I remember correctly Microsoft provides stripped pdb(s) for msvcp140.dll dlls.

They should not be stripped but I wouldn't be too surprised if there's a bug somewhere that they are being stripped.

Are you considering to distribute pdb files with unstripped debugging info that is linked to stl github repo?

No, because the bits that ship in the product Visual Studio aren't derived from this repo directly. (Right now we are manually replaying any changes in here into the DevDiv tree and using the existing build / deployment system from before we went OSS there; that's why there are still msbuild scripts here).

distribute pdbs indexed with github links

That sounds like you're talking about source indexing which I believe we do not do at all at this time.

[jonwil]

Is the intent that at some point in the future the STL bits that ship with the product will be built using this repo (or source that is a direct copy of this repo) or are there things about the way Visual Studio (and its bits including the STL) get built that prevent this from happening?

[BillyONeal]

I don't think we know the answer to that yet. The highest priority is that existing Visual Studio customers' experience remains unaffected by the OSS project. If we can do that building the actual shipping bits here that would be ideal.

[egorpugin]

Any updates?
It would be nice if you tag something as release having VS16.5 released.

[jonwil]

It would be nice to be able to pull a tag from this repo and get source code that (when compiled per the relavent build instructions) produces a binary that is ABI and functionally compatible with the binaries that come with the latest version of Visual Studio 2019.

[StephanTLavavej]

Working on the release notes now. Apologies for the delay.