# dotnet/core: the release-notes and support-policy repository behind .NET > dotnet/core is not a runtime or an SDK. It is the repository that publishes .NET release notes, support phases, end-of-support dates and install links, and it is the first place to check before you pin a version. **dotnet/core** — .NET news, announcements, release notes, and more! - Repository: https://github.com/dotnet/core - Website: https://dot.net - Stars: 22,040 · Forks: 4,936 - Language: PowerShell - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/dotnet-core ## What dotnet/core actually is, and who needs it The repository describes itself as "the home of .NET release notes and news". That is the whole scope. It contains release-notes/, releases.md, release-policies.md, support.md, os-lifecycle-policy.md, linux-support.md, daily-builds.md and a set of licensing files. The primary language listed for the repository is PowerShell, which fits a repository whose main job is publishing text and running release automation rather than shipping compiled artifacts. The audience is narrow and specific. If you maintain a .NET application and need to know which patch is current, which support phase a band sits in, or when a version stops receiving fixes, this is the index. The README table lists four bands with active support or development: .NET 11.0 in Go-Live, .NET 10.0 in Active, and .NET 9.0 and .NET 8.0 in Maintenance. Each row carries a latest patch version and an end-of-support date. It is not for people looking for the runtime itself. The README points to dotnet.microsoft.com/download/dotnet for binaries and installers, and to learn.microsoft.com for installation docs. Nothing here is a package you add to a project. ## How the release-notes tree and the support table fit together The data flow is directory-driven. Each version band has its own folder under release-notes/, and each patch has a markdown file inside it. The README links .NET 11.0 RC 1 to release-notes/11.0/preview/rc1/11.0.0-rc.1.md, .NET 10.0.12 to release-notes/10.0/10.0.12/10.0.12.md, .NET 9.0.20 to release-notes/9.0/9.0.20/9.0.20.md, and .NET 8.0.31 to release-notes/8.0/8.0.31/8.0.31.md. The path encodes the band and the patch, so a link target tells you what you are about to read before you click. The table at the top of the README is the summary layer, and it carries the fields that decide upgrade urgency: release date, release type, support phase, latest patch version and end-of-support date. Release type is either STS or LTS, and the README links both to release-policies.md. Support phase is Go-Live, Active or Maintenance. The separation matters. A patch note tells you what changed in one build. The table tells you whether that build is still receiving anything at all. A team that only reads patch notes can miss the fact that a band has moved into Maintenance, where the support model is different from Active. ## Reading .NET Core versions from the support table The table is the fastest way to answer the question people actually type into search engines: what is the latest .NET Core version. As of the latest release entries, the newest published items are v11.0.0-rc.1, v10.0.12 and v9.0.20, all dated 2026-09-08. The README lists .NET 11.0 with a release date of November 10, 2026 and a release type of STS, currently in Go-Live, with 11.0.0-rc.1 as the latest patch. Its end-of-support date is listed as October 13, 2026. That last pairing deserves attention. A band whose release date is November 10, 2026 and whose end-of-support date is October 13, 2026 is in a pre-release state, and the dates in the table reflect the Go-Live arrangement rather than a finished support window. Anyone building a long-lived service should read the .NET 10.0 row instead: LTS, Active, latest patch 10.0.12, end of support November 14, 2028. That is the row with the longest runway in the table. .NET 9.0 is STS in Maintenance with latest patch 9.0.20 and end of support November 10, 2026. .NET 8.0 is LTS in Maintenance with latest patch 8.0.31 and the same end-of-support date, November 10, 2026. Two bands sharing one end-of-support date is the kind of detail that is easy to miss when you check versions one at a time. ## Where dotnet/core sends you to install .NET dotnet/core does not host installers. The README sends you to dotnet.microsoft.com/download/dotnet for binaries and installers, to learn.microsoft.com/dotnet/core/install/ for installation documentation, and to learn.microsoft.com/dotnet/core/tools/dotnet-install-script for the dotnet-install scripts. Those are the only installation paths named in the repository, and it gives no command sequence of its own. What the repository does give you is the check that follows an install. Once a version is in place by one of those routes, the README table is what you compare against: find your band's Latest Patch Version and End of Support columns, then confirm what the machine reports. If the installed patch is behind the listed one, the end-of-support date in that same row is the deadline that applies to you. For automated installs, the dotnet-install scripts documentation is the relevant destination rather than the download page, because the repository frames the script route as its own topic. Which of the three links applies depends on whether a human or a build agent is doing the work. ## Where dotnet/core stops being useful The repository is documentation, and it behaves like documentation. There is no rollback procedure in the README. There is no version-pinning mechanism, no lock file, no package feed. If you need to move a production fleet between patches, the release notes describe what changed, not how to reverse it. It is also the wrong tool for anything resembling a support contract. The repository links to microsoft-support.md and support.md, and it lists license-information.md and license-information-windows.md alongside LICENSE.TXT, but it does not provide entitlement, escalation paths or response times. Those live outside the repository. The support table is a snapshot of the README at a point in time, and the README itself is the only place the table is maintained. There is no machine-readable feed documented in the repository for the table's contents. The README does document RSS feeds, but for GitHub Discussions categories (all, news, general), not for the support table. A team that wants to automate end-of-support alerts has to watch the file rather than subscribe to a structured endpoint. Finally, the Go-Live row for .NET 11.0 shows how easy it is to read the wrong signal. A version listed with a future release date and a support phase is not the same as a version you should deploy. ## An alternative: the SDK documentation and the download page The most direct alternative for installation questions is the SDK installation documentation at learn.microsoft.com/dotnet/core/install/, which the README lists under Installation docs. The difference in approach is scope. dotnet/core answers which version exists and how long it is supported; the installation documentation answers how to get that version onto a particular operating system, and it is the source the README defers to rather than duplicating. For binaries, dotnet.microsoft.com/download/dotnet is the alternative to reading the table at all. It is the destination the README names for binaries and installers, and it is organized around downloading rather than around support phases. A third route is the dotnet-install scripts documentation. Where the download page targets interactive installation, the script documentation covers automated installation, which is what CI images and build agents typically need. Choosing between them is a question of whether a human or a pipeline is doing the install. None of the three replaces the other two, and the README treats them as a set rather than as competing options. ## Maintenance, licensing and what an upgrade costs you The repository is not archived, and its last push was on 2026-09-16. It is a live repository, but the maintenance that matters to a reader is the maintenance of the .NET bands it documents, not the repository's own commit cadence. That maintenance is scheduled and published. .NET 10.0 is LTS in Active support through November 14, 2028. .NET 9.0 and .NET 8.0 are both in Maintenance with end of support on November 10, 2026, which is the near-term deadline for anyone on either band. .NET 11.0 is STS in Go-Live. The release-policies.md file is where the README points for what STS and LTS mean, and it is the file to read before assuming a band will keep receiving fixes. The upgrade cost is visible in the same table. Moving from .NET 9.0 to .NET 10.0 buys roughly two additional years of support, from November 10, 2026 to November 14, 2028, and it moves you from Maintenance back to Active. That is the concrete trade a team faces this cycle. On licensing, the repository carries LICENSE.TXT and the MIT license identifier, plus license-information.md and license-information-windows.md at the repository root. The MIT licence applies to the repository contents. It does not describe the licensing of the .NET runtime or SDK distributions, which are covered by the separate license-information files the repository points to. Read those files directly rather than inferring distribution terms from the repository licence. ## Conclusion Adopt dotnet/core as a reading habit, not as a dependency: it is the authoritative index for .NET Core versions, patch numbers and end-of-support dates. Teams that need a tested runtime, a support contract or a rollback procedure will not find any of those here, because the repository ships documentation and links to dotnet.microsoft.com/download/dotnet for binaries. Before you pin a version, open release-notes/10.0/README.md and release-policies.md and confirm the patch number and the end-of-support date listed for your band. ## FAQ ### What is dotnet/core used for? It is the home of .NET release notes and news, holding the release-notes/ tree, the support table, release-policies.md and support.md. Teams read it to find the latest patch for a version band and that band's end-of-support date. ### Does .NET Core still exist? The repository lists supported and in-development bands including .NET 11.0, .NET 10.0, .NET 9.0 and .NET 8.0, with patch releases dated 2026-09-08. The naming has moved on from ".NET Core" to versioned .NET, but the release and support process documented here is current. ### How do I install .NET Core? dotnet/core does not host installers. The README points to dotnet.microsoft.com/download/dotnet for binaries and installers, learn.microsoft.com/dotnet/core/install/ for installation documentation, and learn.microsoft.com/dotnet/core/tools/dotnet-install-script for the install scripts. ### What's the difference between .NET and .NET Core? The repository does not draw that distinction. It presents versioned bands (.NET 11.0, 10.0, 9.0, 8.0) with release types of STS or LTS, and points to release-policies.md for what those types mean. ### What is dotnet core framework? The README does not define a "framework" component. It documents release notes, support phases and end-of-support dates for version bands, and links to dotnet.microsoft.com/download/dotnet for binaries and installers. ## Sources - [dotnet/core on GitHub](https://github.com/dotnet/core) - [License: MIT](https://github.com/dotnet/core/blob/main/LICENSE) - [Project website](https://dot.net) - [README](https://github.com/dotnet/core/blob/main/README.md) - [Releases](https://github.com/dotnet/core/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotnet-core