# aspnet/Announcements: a locked issue tracker that is the ASP.NET Core breaking-change index > aspnet/Announcements is not a library and not a source tree. It is a write-only issue tracker where the .NET team posts breaking changes for ASP.NET Core and Entity Framework Core, searchable by label and by release milestone. It is worth watching before an upgrade, and useless as a dependency. **aspnet/Announcements** — Subscribe to this repo to be notified about major changes in ASP.NET Core and Entity Framework Core - Repository: https://github.com/aspnet/Announcements - Stars: 1,660 · Forks: 88 - Language: Unknown - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/aspnet-announcements ## The whole repository is an issue tracker, not a package What sits at the root of aspnet/Announcements is a governance file set and nothing else: a .github directory, CODE-OF-CONDUCT.md, CONTRIBUTING.md, LICENSE.txt, README.md and SECURITY.md. There is no source code, no build definition, no package manifest and no test project. The description says the repository exists so people can subscribe to it and be notified about major changes in ASP.NET Core and Entity Framework Core. That makes the unit of value an issue, not a release. The repository publishes no GitHub releases at all, which is worth stating plainly to anyone who lands here looking for changelogs. If your tooling expects versioned artefacts with release notes, this repository will look empty and will stay empty. The content arrives as issues, each one describing a change, and the organisation is entirely in the labels and milestones GitHub applies to those issues. ## Two labels do all the sorting work The README points readers at two labels: Announcement, for what is new, and Breaking change, for what is different in a way that can break your code. Both are applied within the same repository, so the pair of filters is enough to answer two different questions. Announcement alone gives you the full feed of team posts. Announcement plus Breaking change narrows it to the items that deserve a migration note. The labels are not documented any further. The README does not state who assigns them, whether every breaking change gets the label, or how soon after a decision the issue appears. The only guarantee offered is the subscription: watch Issue events from the repository and you are notified about major changes in ASP.NET Core. For a team with a scheduled upgrade, the practical sequence is to check the Breaking change label first and read the Announcement label second. Breaking changes are what consume engineering time; announcements are context. ## Milestones are the release axis, and the README list stops at 2.0 Each announcement is filed under a milestone named after the release it affects, and the README explains that filtering by milestone is how you find the announcements or breaking changes for a specific release. Every milestone link in the README is a GitHub search scoped to open issues with that milestone, for example the 2.0.0 preview milestones and the final 2.0.0 release. The list itself is the interesting part, because it stops at 2.0.0. The most recent milestone named in the README is 2.0.0, alongside the 1.0.x beta and release candidates, 1.1.0, and the 2.0.0 previews. The repository itself is current, with the last push on 2026-10-05, so the README is simply not being extended with new milestone links as releases ship. Do not read the absence of a link as the absence of an announcement. Construct the milestone query yourself for your target version, and if the filter returns nothing, confirm that the milestone name matches the release naming convention rather than assuming the release was clean. ## Every post is locked and points somewhere else for the argument The README sets an unusual rule: all items posted to the repository are locked. Locking means no new comments, so an announcement is a statement rather than a discussion. The reason given is that every post should carry links to separate discussion threads in the affected repository, and those threads are where questions and comments belong. This has a clear upside for readers. Announcement posts stay short and stable, and the actual argument, the workaround, the migration detail and the objections all live next to the code in aspnet or dotnet repositories where the affected maintainers can answer. It also has a cost: the repository cannot be used as a place to ask whether an announcement applies to your situation. If you are unsure where to post a question, the README's instruction is to log an issue in the aspnet/Home repository. For an automated reader, locked issues are also the most stable thing to scrape. Questions and comments about a particular announcement belong in its linked discussion thread. ## Bugs and discussions belong to a different repository entirely The opening line of the README is a redirect notice: this repository is for team announcements only. To file a bug or start a discussion, the instruction is to find the appropriate repository under the aspnet organisation and open an issue there. General issue discussions go to the aspnet/Home issue tracker. This is the second structural reason the repository has almost no files. It is a one-way valve. Anything the community wants to say goes elsewhere, so what remains here is only what the team itself decided to publish. A repository with no source and a handful of governance files is therefore the expected shape, not a sign of abandonment. A SECURITY.md file is present at the root, though the README does not describe the disclosure process. ## Why watch a repository instead of reading release notes The alternative to this repository is a release-notes page or a migration guide published with each version. The difference is direction and timing. A migration guide is written once, at release time, and describes what changed in the version you are about to adopt. An announcement issue is posted when the decision is made, which can be well before the release ships, and it is filtered by label so you can narrow to the release line you care about. That earlier signal is the reason to keep the subscription on. A breaking change announced months ahead gives a team time to plan, adapt tests, or decide to stay on the previous line. It also gives a team that has deliberately deferred an upgrade a way to know what it will face later. The README does, however, provide GitHub searches based on labels and milestones. There is no feed URL in the README, no export script, and no release tag to diff against. Subscribing to issue events is the only notification mechanism the documentation names, so anyone wanting an automated changelog feed for CI pipelines will have to build that themselves. ## Licence terms need a look before you reuse the text The repository carries a LICENSE.txt at the root and GitHub classifies its licence as Other, meaning a custom licence it does not recognise from the standard set. The README does not summarise the licence terms. The practical read is that the content is published by the.NET team for the community to follow, not as a permissively licensed corpus you can copy into commercial documentation without checking. If you plan to quote announcements in internal runbooks, mirror them, or republish them in a customer-facing changelog, read LICENSE.txt first. The repository metadata classifies the licence as Other, so consult LICENSE.txt for the applicable terms. ## Conclusion Use aspnet/Announcements as a pre-upgrade checklist: subscribe to issue events, then filter by the Breaking change label within the milestone for the release you are moving to, and follow each item's linked discussion thread in the affected repository. It will not help you if you need machine-readable release notes, since the repository publishes no GitHub releases and the README documents no feed or export. The last push was on 2026-10-05, so verify that a milestone exists for your target version before assuming a quiet filter means no breaking changes. ## FAQ ### What is the aspnet/Announcements repository for? It exists so you can subscribe to it and be notified about major changes in ASP.NET Core and Entity Framework Core. The repository itself holds no source code, only announcements filed as issues. ### How do I find breaking changes for a specific ASP.NET Core release? Filter the issue list by the milestone named after the release, and narrow further with the Breaking change label. The README links each milestone as a GitHub search scoped to open issues with that milestone. ### Why can I not comment on an announcement in aspnet/Announcements? All items posted there are locked, by design. Each post links to a separate discussion thread in the affected repository, and those threads are where questions and comments should go. If you are unsure where to post, the README directs you to the aspnet/Home issue tracker. ### Can I file a bug in the aspnet/Announcements repository? No. The README states the repository is for team announcements only, and tells you to find the appropriate repository under the aspnet organisation for bugs and discussions. ### Does aspnet/Announcements publish release notes or GitHub releases? The repository has no GitHub releases, and the README documents no feed or export format. The content lives entirely in issues, organised by the Announcement and Breaking change labels and by release milestone. ## Sources - [aspnet/Announcements on GitHub](https://github.com/aspnet/Announcements) - [Issues](https://github.com/aspnet/Announcements/issues) - [README](https://github.com/aspnet/Announcements/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aspnet-announcements