Jak śledzić ekosystem .NET i być na bieżąco

Kąt widzenia: nie “co nowego w .NET X” (to starzeje się w miesiąc), ale jak czytać ekosystem .NET — skąd brać informacje, jak rozumieć cykl wydań, co faktycznie śledzić na co dzień
Przykład przewodni: roadmapa od .NET Preview do RTM i co z niej wyciągać jako developer

Problem z “aktualnościami” w .NET

Posty o nowościach w .NET mają termin ważności. Artykuł o .NET 9 Preview staje się nieaktualny w dzień premiery .NET 9, a całkiem przestarzały gdy wychodzi .NET 10. Zamiast gonić za każdym preview — lepiej zrozumieć jak ekosystem .NET działa i skąd czerpać informacje gdy faktycznie są potrzebne.

Cykl wydań .NET — co musisz wiedzieć

.NET od wersji 5 (2020) ma przewidywalny, roczny cykl:

Listopad rok N:   .NET N-LTS lub STS
Listopad rok N+1: .NET N+1-STS lub LTS

LTS (Long-Term Support) — wsparcie przez 3 lata. Parzystym wersje: .NET 6, 8, 10… STS (Standard-Term Support) — wsparcie przez 18 miesięcy. Nieparzyste: .NET 7, 9, 11…

W projektach produkcyjnych trzymaj się LTS — masz czas zamigrować bez presji. W nauce możesz używać najnowszej wersji.

Fazy wydania

Preview 1-6 (luty–sierpień)
        ↓
Release Candidate 1-2 (wrzesień–październik)
        ↓
RTM — Release to Manufacturing (listopad)
        ↓
Patch releases (co miesiąc, środa Patch Tuesday)

Preview — funkcje eksperymentalne, API może się zmienić. Nie używaj w produkcji.
RC — “go-live” — możesz testować na staging. API zamrożone.
RTM — pełne wsparcie.

Gdzie śledzić — konkretne źródła

1. .NET Blog — devblogs.microsoft.com/dotnet

Oficjalny kanał Microsoftu. Każda preview, RC i RTM dostaje swój post z listą zmian. Format jest przewidywalny: “What’s new in .NET X” zawiera:

• Performance improvements z benchmarkami
• Nowe API z przykładami kodu
• Breaking changes

Czytaj posty RTM i przeglądaj “What’s New” w dokumentacji — to jest kanoniczne źródło.

2. GitHub — github.com/dotnet

Cały .NET jest open source. Repozytoria które warto śledzić:

dotnet/csharplang to miejsce gdzie możesz śledzić co wejdzie do przyszłych wersji C# — discussions i proposals dają wgląd zanim coś trafi do preview.

3. dotnet/announcements — GitHub discussions

github.com/dotnet/announcements — ogłoszenia breaking changes i security fixes. Jeśli masz projekty .NET w produkcji, obserwuj to repozytorium. Dostaniesz GitHub Notification przy każdym breaking change.

4. C# Language Design — cotygodniowe notatki

github.com/dotnet/csharplang/blob/main/meetings — notatki z cotygodniowych spotkań Language Design Team (LDT). Jeśli interesuje cię jak i dlaczego C# ewoluuje, to jest miejsce. Widać tu jak pomysły na nowe funkcje są argumentowane, odrzucane lub akceptowane.

5. Dokumentacja — learn.microsoft.com/dotnet

Sekcja “What’s New” dla każdej wersji — learn.microsoft.com/dotnet/core/whats-new — jest lepiej zorganizowana niż posty blogowe. Masz wszystko w jednym miejscu z linkami do API docs.

Jak czytać “What’s New” — praktycznie

Nie czytaj linijka po linijce każdej listy zmian. Masz strategię:

1. Sprawdź performance numbers — .NET co roku publikuje benchmarki. To szybko mówi czy nowa wersja ma wpływ na Twoje workloady.

2. Sprawdź breaking changes — learn.microsoft.com/dotnet/core/compatibility — posortowane po wersji. To pierwsze co sprawdzasz przed migracją projektu.

3. Przejrzyj nowe API przez prizmat swoich projektów — jeśli używasz EF Core, sprawdź co nowego w EF. Nie musisz znać każdej nowości w całym .NET.

4. Sprawdź C# language features — to ma bezpośredni wpływ na to jak piszesz kod każdego dnia.

Jak wygląda migracja projektu — co sprawdzić

Migrujesz z .NET 8 → .NET 10? Kolejność:

// 1. Zaktualizuj Target Framework w .csproj
<TargetFramework>net10.0</TargetFramework>

// 2. Uruchom analyzer breaking changes:
dotnet build  // compiler warnings wskazują deprecated API

// 3. Sprawdź NuGet dependencies — czy paczki mają obsługę nowej wersji
dotnet list package --outdated

Strona github.com/dotnet/runtime/issues?q=label%3Abreaking-change — breaking changes z komentarzami jak je naprawić.

C# — jak śledzić nowe funkcje języka

C# releases są powiązane z .NET releases (C# 13 = .NET 9, C# 14 = .NET 10…).

Dla każdej nowej funkcji C# warto szukać:

1. Proposal w csharplang — co rozwiązuje ta funkcja i jakie były alternatywy
2. What’s New in C# X w dokumentacji — oficjalny przykład użycia
3. SharpLab.io — wklej kod C#, zobaczysz IL, decompiled C# i porównanie z poprzednią wersją

// SharpLab.io pozwala zobaczyć co kompilator robi z nowym kodem
// np. jak primary constructors są desugarowane:
public class Point(int x, int y)  // C# 12 primary constructor
{
    // SharpLab pokaże jak to wygląda jako "stary" C#
}

Co faktycznie śledzić na co dzień

Nie musisz czytać wszystkiego. Realistyczny setup:

• Subskrybuj .NET Blog przez RSS lub email — przeczytaj artykuły RTM, pomiń preview (chyba że chcesz testować)
• Obserwuj dotnet/announcements na GitHub — security fixes i breaking changes
• Raz na kwartał przejrzyj “What’s New” dla obszarów których używasz

Reszta (csharplang proposals, design meetings, preview posts) — na żądanie, gdy coś konkretnego Cię interesuje.

Podsumowanie

Ekosystem .NET jest aktywny i przewidywalny — roczny cykl, dobra dokumentacja, publiczne dyskusje o kierunku języka. Wystarczy wiedzieć gdzie patrzeć.