Add README.md for archived runtime packages #570
Conversation
|
cc @jaredpar, @stephentoub, @karelz, @danmosemsft |
|
@ericstj should we consider harvesting (some of those) instead? |
Harvesting? |
| # Microsoft.CSharp package | ||
|
|
||
| We are not accepting feature contributions to Microsoft.CSharp. | ||
| The package is effectively archived. |
There was a problem hiding this comment.
Not sure if this is correct. Archived implies no changes whatsoever.
There was a problem hiding this comment.
The phrase "effectively archived" is being applied to all of our code bases where we're only taking servicing level fixes. It's how we describe the old corefx, coreclr and core-setup repositories for example. These libraries fit into that theme.
There was a problem hiding this comment.
I see. It's up to you what language you use, but it came across as hyperbole to me when the following statement seemed to contradict it. To me, "effectively archived" makes sense for repositories where the code has moved somewhere else for the latest release, it makes less sense when the library is still building out of the codebase and you've just racheted up the bar: nothing has been archived it just has a higher bar.
AKA redistributing old binaries in new packages.
No, since the product still ships these and we support them we need to continue to build them and not extend the lifetime of past servicing branches past the product lifecycle. We should only stop building things that are no longer part of the product. |
| @@ -0,0 +1,8 @@ | |||
| # System.Dynamic.Runtime package | |||
There was a problem hiding this comment.
package here is a misnomer: we don't produce a package for this. It's only in the shared framework. Should this say "library" instead? Same applies to System.Linq.Expressions.
|
I'd still like https://github.com/dotnet/corefx/issues/16287 to be fixed in System.Linq.Expressions since it's a regression from the .NET Framework. Would you be willing to consider this? |
|
Agree with @danmosemsft comment there:
If there was a solid plan for how to bring this back on top of the feature set of .NET Core (given the old emit technology wasn't ported to desktop) then we'd be willing to consider a pull request for that. |
ghost
locked as resolved and limited conversation to collaborators
- The port wasn't opened on the device so the tunnel was never connected properly - Fixing multiple timestamps in logs (cascades of callback/aggregated logs) - Fixing how we log details when waiting for connections Resolves dotnet#570 Testing showed that mlaunch doesn't quit when app is finished though (dotnet#574)
Fixes https://github.com/dotnet/corefx/issues/33170.