Microsoft has shipped Release Candidate 2 of .NET 11, per Heise, putting the framework within touching distance of general availability while a set of breaking changes still has to be absorbed.
The RC stage is the useful signal for anyone planning upgrades. Feature work is done, the API surface is effectively frozen, and what remains is bug fixing and documentation. RC2 arriving in October fits Microsoft's cadence, which has settled on a new major .NET release each November; the .NET 10 line that precedes it is the current long-term-support version.
Breaking changes are the item to act on now. They tend to be small and individually reasonable — the kind of cleanup that accumulates over a decade of platform evolution — but collectively they are what turns a smooth upgrade into an afternoon of build failures. The mechanical response works best: pull the candidate into a branch, build the whole solution, run the test suite, and check warnings-as-errors settings. Most of the fallout surfaces within minutes.
The second thing to check is compatibility switches. Microsoft usually ships opt-outs for the changes most likely to break large codebases, and knowing which ones exist — rather than rewriting immediately — is often the difference between shipping on schedule and stalling.
Developers should work from the official breaking-changes documentation rather than summaries: the authoritative list, the affected APIs and the recommended migration path live there, and it is updated right up to release.
