Runtime: Announcement: Consolidated repo names

[terrajobst]

As we announced earlier, we're planning on consolidating some of the repositories in the dotnet org. While this is still work in progress, we'd like to give you an update on where we are.

So far, we've identified the following repos:

• dotnet/runtime
  
  
  
  • Will contain coreclr, corefx, core-setup, aspnet/Extensions, and some of mono/mono
  
  
• dotnet/sdk
  
  
  
  • Will contain toolset, sdk, cli
  
  
• dotnet/installer
  
  
  
  • Renamed from core-sdk
  
  
• dotnet/aspnetcore
  
  
  
  • Moved from aspnet/AspNetCore and will also contain aspnet/AspNetCore-Tooling
  
  
• dotnet/efcore
  
  
  
  • Moved from aspnet/EntityFrameworkCore
  
  
• dotnet/winforms
  
  
  
  • Unchanged, but listed for clarity
  
  
• dotnet/wpf
  
  
  
  • Unchanged, but listed for clarity
  
  

Name changes

You might notice that we changed our mind on naming from our earlier announcement. Based on your feedback, we decided to go with dotnet/runtime instead of dotnet/platform and dotnet/sdk instead of dotnet/cli.

Several people pointed out that the previous names weren't relatable to how we talk about the product, for example on download pages. So, we decided to match the product distributions as the primary design point for the new names. We generally refer to the bits you need to run your app as the runtime and the bits you need to build apps as the SDK. This also matches the naming chosen by other platforms.

New repos can't be used for .NET Core 3.x or earlier

The consolidated repositories are going to be about .NET 5 and going forward. It will not be possible to build .NET Core 3.1 or earlier from these repositories. As such, only the master branch from each of the repositories will be brought forward. There will be no porting of the individual release branches in the source repositories.

Personal names and email addresses

Since we're planning on rebasing the history in the merged repositories, we can map your name and email address to new values as well. We primarily do this to support our friends in the LGBTQ+ community who have changed their names to reflect their identities. However, anybody is welcome to use this to change their email and name.

Whatever your reason might be: we value your contributions and we hope this small gesture makes your life a little bit better. So if you changed your name/email – or simply prefer us to use different values – please submit a request.

More is coming

We'll share more updates in the upcoming months. Please let us know of any concerns that we haven't addressed yet!

[poke]

What is the reasoning behind putting aspnet/Extensions into dotnet/runtime? The Extension packages (currently) are separate and do not ship directly with the runtime but only the AspNetCore shared framework. The primary access strategy will probably continue to be NuGet.

Migrating it into the runtime will hurt discoverability and may send incorrect signals about the status of those packages.

Most importantly though, merging it with the runtime will have a huge impact for contributors of those packages. Cloning the full framework repo is a very different beast than cloning the extensions repo alone. Even if the build process does not change for those packages, it will make contribution a lot harder than even contributing to ASP.NET Core.

[terrajobst]

What is the reasoning behind putting aspnet/Extensions into dotnet/runtime?

Short answer: future proofing. The goal of the repo consolidation is simplify code flow between repos. dotnet/runtime will produce the core shared framework (Microsoft.NETCore.App). We plan on making the host builder app model available to applications other than ASP.NET Core, such as console apps, desktop apps, and Xamarin apps. In that world, it makes sense to have some of the extension packages part of the core shared framework. In order to realize our code flow goals, this means they have to be in dotnet/runtime. Besides, the CoreFX repo today also contains many foundational packages that aren't in the shared framework. Some even ship in both in-box as well as out-of-box (OOB). We have found that the characteristic of in-box/OOB tends to change over time; hence we tend to err on the side of assuming that a foundational/BCL like component will eventually have to be pushed down, and thus has to be part of CoreFX, and thus dotnet/runtime moving forward.

We understand that this less convenient for contributors. However, we believe having to move repos after the repo consolidation would be worse.

[cilerler]

@terrajobst did I understand it correctly? What you are saying is, we will no longer have a jargon as .NET CORE and ASPNET.CORE, they will both use the same shared framework, NET CORE will be the base, and ASP.NET CORE will be the services added on it (routing, endpoints, razor, etc.)

[huoyaoyuan]

What about CoreRT? Won't it get consolidated, at least partially, into the runtime repo?

[dallmair]

Why do you intend to keep the aspnetcore and efcore names? Per this announcement, the repo consolidation is all about .NET 5 and per @terrajobst's answer to @poke above, it's about future proofing for that era. Also, per the announcement blog post [1] you're going to drop the "Core" part from the naming for .NET 5 -- so why would you keep it in ASP.NET (Core) and Entity Framework (Core) repository names? Why not just name these aspnet and ef (or entityfx if you think ef is too short)?

[1] https://devblogs.microsoft.com/dotnet/introducing-net-5/

[poke]

@dallmair ASP.NET and ASP.NET Core, just like EF and EF Core are separate and incompatible things. While I could see then eventually dropping the “Core” from the names, I strongly recommend (and did so on the past) not to do that. That will just lead to confusions that cannot be fixed easily. For example, “ASP.NET 5” was already a thing (it's the precursor to ASP.NET Core 1.0), and “Core” was added to highlight that it's a separate and incompatible _new_ framework.

[alpencolt]

@huoyaoyuan it's already merged to CoreCLR as part of crossgen2 https://github.com/dotnet/coreclr/commit/ce1c7ed76cc113396cbbf25329b99089af6cc784#diff-811b62aeee4fd1c10176202513f4292b

[MichalStrehovsky]

@huoyaoyuan it's already merged to CoreCLR as part of crossgen2 https://github.com/dotnet/coreclr/commit/ce1c7ed76cc113396cbbf25329b99089af6cc784#diff-811b62aeee4fd1c10176202513f4292b

@alpencolt That's a part of the CoreRT AOT compiler relevant for ReadyToRun that is going to ship in .NET 5. We didn't move the full AOT parts of the compiler or the CoreRT runtime itself (those keep the "experimental" label and weren't part of the move).

[jaredpar]

What about CoreRT? Won't it get consolidated, at least partially, into the runtime repo?

Pieces of CoreRT will be merged into dotnet/runtime but the repo itself as a whole will not be merged.

[dallmair]

@dallmair ASP.NET and ASP.NET Core, just like EF and EF Core are separate and incompatible things.

Similar to how .NET and .NET Core are separate things.

While I could see then eventually dropping the “Core” from the names, I strongly recommend (and did so on the past) not to do that. That will just lead to confusions that cannot be fixed easily. For example, “ASP.NET 5” was already a thing (it's the precursor to ASP.NET Core 1.0), and “Core” was added to highlight that it's a separate and incompatible _new_ framework.

Yeah, I've been on .NET since v1.1, and remember those past decisions and the confusions they caused.

But it's exactly confusions that worry me here. From my point of view, keeping the names as announced will cause confusions in the future as it means that we'll see a .NET 5 release next year (without "Core"), which won't be able to run ASP.NET (without "Core"). That's inconsistent and not totally obvious for everyone, i.e. it will cause confusion.

So why risk another round of confusions regarding Core and non-Core? Why not simply drop "Core" everywhere and move on? The newer parts on the stack didn't even get the Core marker to begin with (e.g. dotnet/winforms).

I think there's a simple logical relation in many aspects of software: Consistency => less confusion and inconsistencies => more confusion. All I intended to do in my comments and questions was to point out an inconsistency and hopefully get a glimpse on the discussion and their reasoning from those directly involved in the decision. Sorry that I failed to convey that in my first comment.

[terrajobst]

@dallmair

The motivation for using just ".NET" as the branding for the platform is much larger than ASP.NET or EF -- it's about incorporating all the various pieces that make up our platform, .NET Framework, .NET Core, .NET Standard, and Xamarin. We have too many competing "brands" for what amounts to be the platform itself. With .NET 5, the plan is to converge these models in such a way that we don't have to explain that many different things anymore.

In a strict sense, ASP.NET Core and EF Core aren't platforms, but application models on top of the .NET platform. They are siblings to WPF, WinForms, Xamarin Forms, and (in the future) Blazor. While I can see value in dropping the Core branding for the application models too, the downside is confusion. Keep in mind that for both ASP.NET Core and EF Core the "Core" name is part of the namespaces too. Completely removing the term there isn't feasible.

At the same time, we need to simplify the .NET stack by converging concepts so that we can remove some boxes from the layer cake. And that's what .NET 5 is really about. Dropping the "Core" branding for the platform component helps, but it's not the higher order bit. See my comment here for more details.

[deinok]

@terrajobst When will the merge start for dotnet/runtime?

[jaredpar]

@deinok

When will the merge start for dotnet/runtime?

Unknown. Up until now we've been primarily in a fact finding stage in understanding the work that will be involved to make this happen. Specifically, but not limited to, items like the following:

• Ensuring all repositories use compatible toolsets
• Work required to make the repositories depend on live builds of each other vs. LKG packages
• How we will be mapping commits into the new repository
• Figuring out a plan for the combined CI setup that produces a reasonable experience

In the recent week we've started some experiments on a demo-d up repository and that will continue into next week. After that we should be in a place to actually share out a schedule on when the merges will happen.

[KevinCathcart]

If it will not be possible to build 3.1 from the new repositories, then how will servicing for 3.1 be done? In the old repositories? If so, then they cannot be archived, which could be confusing.

Also is rebasing only planned for "runtime" and "sdk"? I would imagine that it would not be needed for the rest, and would be unnecessarily disruptive if done to them. Certainly I think aspnetcore contributors would be annoyed by that, especially since the great disruptive repository combining event for them was so recent.

[terrajobst]

If it will not be possible to build 3.1 from the new repositories, then how will servicing for 3.1 be done? In the old repositories?

That is correct.

If so, then they cannot be archived, which could be confusing.

Sadly, that's also correct. I've submitted a request to GitHub to split archival from read-only. However, given my experience with filing GitHub feature requests I don't expect this to become available any time soon. So we'll probably do the following:

• Update repo description and include the word DEPRECATED at the very beginning.
• Change issue and PR templates that tell people that you shouldn't do this anymore.
• Transfer new issues submitted by the community
• Close new PRs submitted by the community

No ideal, but workable.

Also is rebasing only planned for "runtime" and "sdk"? I would imagine that it would not be needed for the rest, and would be unnecessarily disruptive if done to them. Certainly I think aspnetcore contributors would be annoyed by that, especially since the great disruptive repository combining event for them was so recent.

That's up to each repo owner I think. The biggest gains are probably for the runtime and SDK repos.

[xsoheilalizadeh]

As I mentioned in previous announcement, do you have any plan to move Xamarin to dotnet org repo?

[huoyaoyuan]

There are many CI pipelines defined in corefx and coreclr. It'll be wasting if PR with change in a small part causes all the pipelines to run again.

[stephentoub]

There are many CI pipelines defined in corefx and coreclr. It'll be wasting if PR with change in a small part causes all the pipelines to run again.

Which legs run will be determined by the changes made.

[aL3891]

I totally understand the resistance to remove the "core" from asp.net core, but just for the sake of discussion, since .net5 is a major version anyway, wouldnt it be possible to change the namespaces? It feels like the oppertunity to make all the names consistent is now, and wont really come again for a long time :) asp.net "core" make sense now, but will in once .net 7, 8 or 9 comes around?

Especially for the actual repo name.

In for a penny, in for a pound as they say :)

[Nirmal4G]

@terrajobst

I agree with @aL3891

I know it's a lot to ask. Bet, you have already discussed with many others. BUT please remove the core from dotnet/aspnetcore and dotnet/efcore

You can still keep all the Core in the namespaces and branding, until a major revision comes along after .NET 5.

[Nirmal4G]

More importantly as @dallmair said, What we think are different than what you think.

E.g.: You have renamed platform to runtime and cli to sdk

So, If you want to drop the Core then drop it everywhere... WinForms and WPF don't have it. PowerShell dropped it. If it's not time, then at least drop them everywhere except the namespaces.

[guardrex]

@terrajobst

We plan on making the host builder app model available to applications other than ASP.NET Core, such as console apps, desktop apps, and Xamarin apps.

ASP.NET Core and EF Core aren't platforms, but application models on top of the .NET platform. They are siblings to .......

Today, .NET Core extensions and host builder docs are maintained in the ASP.NET Core doc set in the Fundamentals node.

In the future, will app model doc sets maintain their own host builder/extensions coverage as we do today, or do you plan to centralize and generalize the coverage in the .NET Core doc set?

[Varorbc]

@terrajobst why not move core-sdk to sdk repo?

[terrajobst]

@terrajobst why not move core-sdk to sdk repo?

Because it really contains the setup/installer and for code flow it sits higher in the build orchestration.

[danmosemsft]

This issue has served its purpose.