Core: .NET Core master branches have switched to "5.0"

[richlander]

.NET Core master branches have switched to "5.0"

Various .NET Core repos have switched their master branches to "5.0", and will use 3.x branches for 3.0 and 3.1 projects. This is very similar to how we approached 2.x and 3.0 projects. As context, master branches produced 3.0 builds for the entire period of the 2.2 project.

At present, this change is only relevant if you contribute to .NET Core repositories. Otherwise, we recommend that you wait for the 5.0 Preview releases before installing this new version.

Details

The following repos have moved their master branches to "5.0":

• dotnet/coreclr
• dotnet/corefx
• dotnet/core-setup

You can see that 5.0 .NET Core Runtime builds are now being built and published at dotnet/core-setup.

In large part, we switched master to 5.0 to enable to the community to contribute changes. As the .NET Core 3.0 released has progressed, we've had to increase scrutiny on the changes we will accept. Now that we've permanently branched for 3.0, we can accept a much broader set of changes. Please consider that to be an open invitation!

Notably, dotnet/core-sdk is not yet producing 5.0 builds. We expect that the dotnet/core-sdk master branch will continue as a 3.0 branch for 2-3 months while we finish up the .NET Core 3.0 project.

At present, there is no developer experience for 5.0. We are waiting on the dotnet/core-sdk repo to switch to 5.0. Switching your project file to target netcoreapp5.0 won't do anything useful. We'll update this issue when a 5.0 SDK comes available.

[marcusturewicz]

Great news Rich! Really looking forward to using .NET 5.

Given the name "Core" will be dropped in 5 onwards, what is the story for the repositories/target frameworks etc? Will we have dotnet/fx, dotnet/clr, dotnet/sdk etc? Will it be netapp5.0?

[richlander]

@stephentoub is currently thinking about that topic. It is unlikely that we’ll rename existing repos. He is thinking about going the “mono repo” route (in this case “mono” means “monolithic”). Some things would be worse with the mono repo approach, but many things would be better like building a feature that requires runtimes and framework changes.

[marcusturewicz]

Agreed. It will also be easier for the community to contribute to a mono repo since the majority of the modules are housed together, and folks can see everything happening in the one place.

[GSPP]

What is worse with a mono repo?

[Nirmal4G]

Git VFS to the rescue, folks!

[perlun]

@GSPP

What is worse with a mono repo?

Quoting the "Limitations and disadvantages" from the Wikipedia article:

• Loss of version information – Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning.[8]
• Lack of per-project security – With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues.[9]
• More storage needed – With split repositories, you can fetch only the project you are interested in. With a monorepo, you'll typically have to fetch all the repositories. Note that there are mitigations to this (like partial fetching).

---

I personally find that the "loss of version information" is one of the bigger issues. Since a git tag marks the _whole_ repo at a given commit, this makes it slightly awkward with monorepos if you release the individual packages independently from each other. You have to use some foo-1.2, bar-2.3 scheme where you prefix the tag with the component/package name to work around this, and even so, it makes e.g. GitHub releases slightly more awkward to work with (all the releases for _all_ the packages will be listed, making it harder for users to find the release info for a given package & version).

All things considered though, I do think that the monorepo approach might make a whole lot of sense for something like the .NET SDK and runtime.