Add documentation for re-bootstrapping the VMR #4247
Conversation
ghost
added
MichaelSimons
requested review from
ellahathaway and
oleksandr-didyk
and removed request for
premun
| Re-bootstrapping is necessary when .NET takes a dependency on new functionality | ||
| added within the bootstrap toolset. For example suppose a new compiler feature is | ||
| added. In order for a repo to take a dependency on the new feature, a re-bootstrap | ||
| would be necessary. |
There was a problem hiding this comment.
Add something like:
The implication of this, and the restrictions of when re-bootstrapping is allowed, means that repos should, in general, wait to take a dependency on a new toolset feature until after that feature has been released.
| build that best matches the dotnet-source-build. The following is the suggested | ||
| order of precedence for finding the best match. | ||
| 1. A build from the same commit. From a VMR commit, you can find the | ||
| corresponding installer commit by looking at the [source-manifest.json](https://github.com/dotnet/dotnet/blob/main/src/source-manifest.json). |
There was a problem hiding this comment.
The dotnet-source-build run has a tag with the installer SHA it corresponds to.
There was a problem hiding this comment.
Will that still be a thing when the VMR becomes its own thing, when we stop syncing it from installer?
There was a problem hiding this comment.
Well, technically, the build will still have the corresponding tag if we don't remove it but maybe we will be producing the bootstrap SDK in dotnet-unified-build?
There was a problem hiding this comment.
This document will need adjustments one the MSFT build starts being produced from the VMR/UB. I will make note of the build tag.
Co-authored-by: Matt Thalman <mthalman@microsoft.com>
4 participants
No description provided.