Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Migrating dotnet/extensions content to dotnet/runtime and dotnet/aspnetcore #411

Open
analogrelay opened this issue Mar 12, 2020 · 1 comment
Open

Migrating dotnet/extensions content to dotnet/runtime and dotnet/aspnetcore #411

analogrelay opened this issue Mar 12, 2020 · 1 comment

Comments

@analogrelay
Copy link

analogrelay commented Mar 12, 2020 •
edited
Loading

Please use dotnet/aspnetcore#19806 for discussions on this topic

As part of the ongoing repository consolidation effort in .NET 5, we are working to move most of the content from dotnet/extensions into other repositories. Most of these packages were developed by and are currently maintained by the ASP.NET team. However, moving forward we want to enable more scenarios with these packages, outside of ASP.NET.

The packages which we believe are usable in various application models (Configuration, DI, Hosting, etc.) are being moved to the dotnet/runtime repository. Packages which are primarily used in ASP.NET Core applications (Web Encoders, etc.) are moving to the dotnet/aspnetcore repository. Finally, in order to avoid introducing third-party dependencies into dotnet/runtime and dotnet/aspnetcore, some packages are remaining in the dotnet/extensions repository as they have dependencies on third-party packages (such as integrations with StackExchange.Redis and other components).

The full list of packages that are moving can be found at the end of this announcement. In general, tests and samples will be moving to the relevant repo based on where the main package moved. Issue tracking for the relevant packages will also move to that repository.

PR/Issue migrations

There are 400+ open issues and ~50 open PRs (at time of writing) in dotnet/extensions.

Since we are actively working on migrating the packages now, we recommend waiting to open new PRs until we update this announcement indicating the migration is complete. Some packages are building in two repositories and we want to make sure your changes land in the right place. Over the migration process, we'll be closing most of the active PRs that target packages which have been moved and asking the author to migrate the PR to the relevant repository.

For issues, feel free to continue opening them and we'll respond to them as best we can during the migration. If the package your issue relates to has been moved, we'll handle transferring the issue. We'll be doing some triaging of the incoming issues and the backlog and will attempt to migrate as many issues as possible. As part of this process, we'll also close issues that are no longer relevant, duplicates of other issues, or enhancements we don't plan to support.

Q&A

If your question isn't answered here, use the Discussion Issue linked at the top of this announcement to ask it!

Are these packages moving in to the Base Class Library ("BCL"), or Microsoft.NETCore.App?

We do not plan to change how these components ship as part of this migration. Packages that currently ship on NuGet.org will continue to do so. Libraries that are currently included in ASP.NET Core will continue to be included. We are not adding any of these components to the BCL at this time.

If package Microsoft.Extensions.X is moving to the runtime repo, why not rename it to System.X?

While it is possible to rename assemblies and redirect type references, it is not possible to change package identities, namespaces or type names in a non-breaking way. Renaming these types would be extremely disruptive and provide very little benefit. All of these components are already covered by the .NET Core Support Policy and will continue to be in the future, just like the System.* assemblies.

Will these packages still support .NET Standard 2.0?

We do not plan to reduce the set of frameworks these packages can be used on as part of this migration. If they currently support .NET Standard, we have no plans to change that.

Why are some packages staying in dotnet/extensions?

As a general rule, we want to avoid third-party dependencies in the dotnet/runtime and dotnet/aspnetcore repositories. The packages that depend on third-party dependencies are remaining in dotnet/extensions to help preserve this.

Where should I file issues related to these packages?

In general, file issues in the repo that contains the package. Some feature areas are split between multiple repos. If you're not sure, feel free to file issues in any of the three repos (dotnet/runtime, dotnet/extensions or dotnet/aspnetcore) and the team can transfer the issue as needed.

Why did you move package X to repo Y?

Feel free to use the Discussion Issue linked at the top of this announcement to ask questions about specific packages.

Package List

The following list identifies all the packages we currently ship from dotnet/extensions and which repo they are moving to.
@analogrelay analogrelay mentioned this issue Mar 12, 2020
Closed
@analogrelay analogrelay reopened this Mar 12, 2020
@aspnet aspnet locked as resolved and limited conversation to collaborators Mar 12, 2020
@JunTaoLuo
Copy link

Here's a small update to the original announcement. We are moving three more packages to AspNetCore in 6.0 and beyond:

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@analogrelay @JunTaoLuo