Skip to content

Conversation

@dkurepa
Copy link
Member

@dkurepa dkurepa commented Oct 30, 2025

Currently msbuild link has a 10.0.1xx VMR build.
This is wrong as it should come from main.
This PR changes the Source tag to a main build, after which we'll need to do a forward flow, and only then a backflow

@dkurepa dkurepa requested a review from a team as a code owner October 30, 2025 15:39
Copilot AI review requested due to automatic review settings October 30, 2025 15:39
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR updates the version details by changing the source repository SHA and BarId references for the dotnet/dotnet dependency. This appears to be a routine dependency update to point to a newer commit in the upstream repository.

  • Updates the source SHA from d499f9cdfd5b7b7bb291f95a3c14417d5edc969f to cdc420f453860b662a76fcc72672ed2a65243146
  • Updates the BarId from 287756 to 288940

@rainersigwald
Copy link
Member

Should it come from vmr main or VMR release/10.0.2xx, which is the next SDK release that our main will flow to?

@dkurepa
Copy link
Member Author

dkurepa commented Oct 30, 2025

Should it come from vmr main or VMR release/10.0.2xx, which is the next SDK release that our main will flow to?

I'm not sure, I'm operating with the subscription information we have:

  • Currently VMRs main (11.0.1xx SDK channel) is configured to flow to main
  • Msbuild main (VS 18.1 channel) is configured to flow to both main and the 10.0.2xx branch

So technically, msbuild main could be getting backflows either from the release/10.0.2xx or the main branch

@rainersigwald
Copy link
Member

Yeah, that makes sense--the most recent backflow in our repo could be from either of those sources. I guess I'm not sure what the change in this PR affects?

@dkurepa
Copy link
Member Author

dkurepa commented Oct 30, 2025

Yeah, that makes sense--the most recent backflow in our repo could be from either of those sources. I guess I'm not sure what the change in this PR affects?

Currently the service is not able to do a backflow, because the VMR commit it currently has is not an ancestor to the commit we're trying to backflow.
This PR unblocks that by setting it to the latest commit from VMRs main.
Technically, after this PR has been merged, backflows will be unblocked, but we shouldn't do them yet, as we might lose some changes.
To make sure we don't lose anything, after this change has been merged and we get a new build, we'll need to open a forward flow it to the VMR, and then backflow once a VMR build with the FF flow commit exists (this is because of the algorithms in the service)

@dkurepa
Copy link
Member Author

dkurepa commented Nov 3, 2025

@rainersigwald do you think we can merge this PR?

@rainersigwald
Copy link
Member

Our main is currently blocked, but we can merge as soon as it's open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants