Servicing branches for releases

[ayakael]

Contrary to many other dotnet components, roslyn does not have servicing branches for various SDK versions. This complicates things when we want to backport changes from main.

For example, Fedora and Alpine packaging teams have a patch for fixing roslyn on mono that has been in main for a year. It'd be nice if we could backport it to release/6.0.1xx so that we can all benefit from each other's work. This is especially important now that more distributions are creating packages and porting to new platforms.

@MichaelSimons @omajid

Related Issue:
dotnet/source-build#3087

[ayakael]

For reference, source-build for release/6.0.1xx uses commit 487283bcd8d66693091f2800dcf1c8ae37cccdee. It'd be nice if that was attached to a release/6.0.1xx branch on GitHub for me to open up a MR to backport the referenced mono fix.

[jaredpar]

I agree it would be nice if we had matching branches like this. It would actually solve a lot of other problems we have. We've considered this a few times but we cannot find a reasonable way to due this with the current set of restrictions that we have in place without adding a lot of overhead.

The rough restrictions we have:

• All of our release branches must be protected (no direct pushes)
• All of our release branches must go through our test suite
• Our repository must have a branching structure that matches Visual Studio releases (true for any component that dual inserts into VS and SDK).

For us, and any other component that dual inserts into VS, we're always simultaneously dealing with a VS and .NET SDK release. The code we insert into them is the exact same commit. So at that level there is no value in having differing release branches. It's the same code, just going to two different places. Two branches is overhead. It also means processes like PRs, CI, official builds, signing, etc ... happen twice (these are reasonbly expensive tasks).

Worse is that at any point in time we are always dealing with two different VS releases: current servicing and next. By extension we're also dealing with two .NET SDK releases (total of four releases which compounds the overhead).

If there were a way to simple have a branch in GitHub that mirrored another branch, and we were flowing source not binaries, I'd be very much in favor of doing that. It would make our relationship with the .NET SDK much clearer. But given our constraints we see no way to make this happen. Everything is some amount of code flow that must go through PRs that retriggers our extensive set of suites. That wastes resources, increases the hit of flaky test failures, etc ... It's overhead that exceeds the provided value.

We did consider tricks like altering our yml files that such that we don't run the full set of tests when merging into .NET SDK release branches but that felt easy to mess up. It also doesn't solve the issue around official builds.

So for the moment we aren't really in a position to do this. If the VMR becomse how we ship on Windows / Linux it would be valuable to revisit this.

[omajid]

Not to put words in @ayakael's mouth, but my main point of confusion has always been "I need to send a fix to .NET 6.0.1xx; which roslyn branch should I target?" I think that might be easier to resolve. Perhaps the README can include a list of which branch of this repo maps to which .NET SDK branch (if any)? Or even the other way around something like:

---

.NET SDK branch mapping

• For changes for release/6.0.1xx, target release/dev17.1

[ayakael]

Not to put words in @ayakael's mouth, but my main point of confusion has always been "I need to send a fix to .NET 6.0.1xx; which roslyn branch should I target?" I think that might be easier to resolve. Perhaps the README can include a list of which branch of this repo maps to which .NET SDK branch (if any)? Or even the other way around something like:

.NET SDK branch mapping

• For changes for release/6.0.1xx, target release/dev17.1

Right, indeed. The problem is that release/dev17.1 is a lot newer than what's referenced in release/6.0.1xx of installer. In fact, the referenced patch is already in that branch. Its current global.json even requires 7.0.100-preview.2.22153.17. Maybe it's a fluke, perhaps release/6.0.1xx does have a branch, just with a different name.

[omajid]

Yeah, I was just giving an example. I don't know the branch matching release/6.0.1xx either 😢

[omajid]

Any thoughts, @jaredpar ?