Arcade guidance does not recommend .NET 3 Eng for all tooling repositories

[agocke]

Every tooling repository, i.e. repositories which also insert into Visual Studio, should almost certainly be on .NET 3 Eng, since every release is a servicing release for Visual Studio.

In addition, inserting into .NET 3 SDK branches is not necessarily kept up-to-date in the .NET 5 Arcade, which caused Roslyn to miss an insertion into Visual Studio 16.6 Preview 2.

Arcade should have clear guidance that anyone inserting into Visual Studio should stay on .NET 3 releases until .NET 5 RTMs.

[agocke]

It looks like the lack of #2208 is blocking us from .NET 3 Eng. It'll have to be backported.

cc @markwilkie @mmitche

[markwilkie]

If you could open a PR @agocke with the port, and fill out the template, we should be able to approve no problem.

[mmitche]

We have also ported the 3.1.3xx channel to master so you can stay there too.

[agocke]

I don't think so. @rainersigwald's point was correct. Since every VS release is a servicing event for us, we should stay on a servicing Arcade.

[tmat]

Since every VS release is a servicing event for us, we should stay on a servicing Arcade.

I don't understand what you mean by this. We are certainly not treating VS updates (16.6, 16.7, etc.) as servicing events. They are new versions. Only after the updates release updating those bits is servicing (16.6.1, 16.6.2, etc.).

If we stay on .NET 3 and corresponding Arcade SDK we won't be dogfooding anything for a year, unless it's backported to 3.x.y. That's not great.

[agocke]

We are certainly not treating VS updates (16.6, 16.7, etc.) as servicing events

They are serviceable releases, meaning that we need to continue servicing them until the next release.

[tmat]

I see.

[tmat]

Seems like it would make sense if Arcade's primary dev branch was the latest 3.x release then, so that all repos automatically get all the new features.

[mmitche]

@tmat That would be basically guaranteed to break older version of .net core. It would also remove the ability for us to dogfood the compilers by checking in new roslyn's to arcade, since we would not want that risk in servicing branches.

They are serviceable releases, meaning that we need to continue servicing them until the next release.

They're serviceable, but only serviceable for a relatively short period of time (vs. .NET Core 3.1). So tooling repositories have an issue where they are on the "edge" for a short period of time when their outputs are both targeted to .NET 5 as well as the latest VS previews. It makes sense during those times to simply be on the latest arcade.

What about the tooling branches mapping to VS releases simply stop updating arcade after they go into 'servicing' mode? That's effectively what 3.x is. We don't want an arcade per VS release because of the overhead, difficulty in knowing what needs to get checked in where, probable lack of interesting changes in most of the servicing channels, etc, but we could choose to make targeted branch+fixes where necessary when one of the VS releases currently in servicing needs something new from arcade.

/cc @markwilkie

[markwilkie]

Arcade should have clear guidance that anyone inserting into Visual Studio should stay on .NET 3 releases until .NET 5 RTMs.

Yes, I think this is the guidance.

Teams like msbuild don't plan to move to net 5 Arcade until net 5 is (at least) go-live because until then, they're also in the 3.x sdk. Of course, they are forgoing the latest features of 5 for the stability of 3. If there are blocking fixes needed, then they'll be ported as normal according to the policy.

Are the gaps w/ this plan/approach? If not, I'll update https://github.com/dotnet/arcade/blob/master/Documentation/Policy/ArcadeServicing.md

[rainersigwald]

I feel like you're not agreeing with each other @mmitche @markwilkie. And I like Mark's answer better.

They're serviceable, but only serviceable for a relatively short period of time (vs. .NET Core 3.1).

Not really? For example 16.4 will be serviced for years. See the external promises at https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing.

What about the tooling branches mapping to VS releases simply stop updating arcade after they go into 'servicing' mode?

If this is accompanied by an SLA acceptable to VS for issue resolution from the Arcade team on that daily build for the life of the VS release, that seems fine. But I don't think Arcade would want to provide that--and indeed I don't think you have the ability to do so (with retroactive branching).

[mmitche]

I feel like you're not agreeing with each other @mmitche @markwilkie. And I like Mark's answer better.

They're serviceable, but only serviceable for a relatively short period of time (vs. .NET Core 3.1).

Not really? For example 16.4 will be serviced for years. See the external promises at https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing.

What about the tooling branches mapping to VS releases simply stop updating arcade after they go into 'servicing' mode?

If this is accompanied by an SLA acceptable to VS for issue resolution from the Arcade team on that daily build for the life of the VS release, that seems fine. But I don't think Arcade would want to provide that--and indeed I don't think you have the ability to do so (with retroactive branching).

I thought about this more. I think it's fine to be on the 3.x branch of arcade (or 5.x when that happens) as long at this does not imply undue churn into the 3.x branch. it can't imply that 3.x is the main development branch of arcade.

[markwilkie]

PR is out. #5247