You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the VMR is synchronized based on the dotnet/installer repository mapping its commits 1:1 with dotnet/installer. This will have to change once we switch over to the full code backflow model.
As laid out in the Unified Build design documentation, the planned code flow for .NET 9 will change and the individual repositories will only receive and send updates from/to the VMR and not between each other, so the situation looks like this (see VMR Code and Build Workflow for details):
The updates of the VMR will no longer happen when dotnet/installer is updated but rather whenever a new build appears in one of the channels. The information making the builds of the dev/17.4 branch of dotnet/roslyn end up in the 7.0.3xx SDK band is stored in the configuration of Maestro subscriptions between those branches. The Maestro service will have to follow this configuration and update the corresponding sources (the right folder of the right branch) of the VMR accordingly. It will also have to flow changes the other way too when a change is made in the VMR or when VMR produces a new build output package. This is all new functionality that Maestro will have to implement.
Goal
The goal is to design and implement this dependency flow system.
Then a plan will be created for product repositories onboarded onto the new dependency flow.
Finally, the plan will be executed and the repositories moved onto the new code flow.
The text was updated successfully, but these errors were encountered:
Context
Currently, the VMR is synchronized based on the
dotnet/installer
repository mapping its commits 1:1 withdotnet/installer
. This will have to change once we switch over to the full code backflow model.As laid out in the Unified Build design documentation, the planned code flow for .NET 9 will change and the individual repositories will only receive and send updates from/to the VMR and not between each other, so the situation looks like this (see VMR Code and Build Workflow for details):
The updates of the VMR will no longer happen when
dotnet/installer
is updated but rather whenever a new build appears in one of the channels. The information making the builds of thedev/17.4
branch ofdotnet/roslyn
end up in the7.0.3xx
SDK band is stored in the configuration of Maestro subscriptions between those branches. The Maestro service will have to follow this configuration and update the corresponding sources (the right folder of the right branch) of the VMR accordingly. It will also have to flow changes the other way too when a change is made in the VMR or when VMR produces a new build output package. This is all new functionality that Maestro will have to implement.Goal
The text was updated successfully, but these errors were encountered: