Runtime: Archiving stable runtime packages

[jaredpar]

There are several packages in dotnet/corefx where the package and supporting language features are mature and no longer evolving, and where the risk of code change likely exceeds the benefit. Those packages should be effectively archived.

Packages:

• Microsoft.CSharp
• Microsoft.VisualBasic
• System.Dynamic
• System.Linq.Expressions

When archived, we would not accept features contributions to the packages. We would consider changes that address significant bugs or regressions, or changes that are necessary to continue shipping the binaries. Other changes will be rejected.

There is one exception: Microsoft.VisualBasic is currently being ported to .NET Core and we will continue to accept contributions that are within the scope of the porting effort.

README.md files will be added to the root of each affected package.

[karelz]

Tagging some most active contributors in the area and in the repo for awareness (sorry if I missed anyone): @hughbe @JonHanna @justinvp @bartdesmet @jamesqo @MarcoRossignoli @AlexRadch @filipnavara @benaadams @jbhensley @svick @GSPP

[iainnicol]

This is understandable. As said, these are mature assemblies, and there is risk to changing them. Moreover, two of these assemblies are language specific.

However, I'm curious about how it affects issue dotnet/runtime#19615. Namely, Microsoft.VisualBasic.dll as it existed in netcore v1 and v2 had low test coverage. (Of course, for the netcore v3 additions, tests are being added).

So, for improving test coverage, would that need to be done before the freeze date?

[jkotas]

This list should include more assemblies, e.g. System.Runtime.Serialization.Formatters (binary serialization) should be in the archived list as well.

[svick]

I'm not sure those are libraries that are "no longer evolving". Specifically:

• I think Microsoft.CSharp sometimes needs to be updated so that changes in the C# language also work with dynamic. For example, https://github.com/dotnet/corefx/pull/25819 was created because of C# 7.2 feature "non-trailing named arguments".

  Microsoft.CSharp is already lagging behind the C# compiler, see https://github.com/dotnet/roslyn/issues/24815.

• System.Linq.Expressions might need to be updated if the C# team decides to implement https://github.com/dotnet/csharplang/issues/158 in the future. (The last status on that from June 2018 is: "For now, let's mull it over for a couple of months, pursue information, crisp up the plan. Only after a while will we be able to free up compiler resources.")

Or would those changes fall under those that are allowed on archived packages?

[jaredpar]

@svick that one change though to Microsoft.CSharp is the exception, not the rule. In general new features have not made their way to having dynamic or expression tree support for several releases now. There aren't any plans to pick up the pace on this at this time.

In the event we did decide to bring more language features back then yes we'd need to un-archive these projects.

[vermorel]

I disagree with the maturity status of System.Linq.Expressions: this package does not support any of the recent .NET constructs like Span<T>, stackalloc and ref struct.

[ltrzesniewski]

Also, System.Linq.Expressions is currently lacking the CompileToMethod method, as stated in dotnet/runtime#20270.

[joperezr]

@jaredpar looks like most of these are not being live built anymore (all except for Microsoft.CSharp). Do we want to move this to Future or do we want to keep this as 3.0?

[joperezr]

Moving to Future given that this doesn't need to happen before 3.0