.NET 8 og C# 12 er klar! Er dit projekt klar til dem?
I november måned blev ikke kun .NET 8, men også C# 12 udgivet.
Værd at bemærke i denne forbindelse:
.NET 8 er en Long Term Support (LTS) release og er garanteret officiel support fra Microsoft frem til 10. november 2026 (3 års support). Alle nye .NET-projekter bør derfor starte her, medmindre særlige omstændigheder taler imod.
Dette i modsætning til forrige .NET 7, som har Standard Term Support (STS) og som slutter kommende forår, 14. maj 2024 (1½ års support). Ingen nye .NET-projekter bør starte med denne version.
.NET 6 er forrige LTS release, hvor support slutter næste efterår, 12. november 2024. Er man bagud, kan .NET 6 bruges som trædesten på vej mod .NET 8+.
Alle tidligere versioner af .NET (Core) er out-of-support, herunder .NET 5 og den udbredte LTS-release .NET Core 3.1. Sidstnævnte gik out-of-support 13. december 2022.
... og sådan fortsætter det i en skemalagt rytme de næste mange år (eller indtil Microsoft ombestemmer sig). Løbende opdatering af .NET-projekter er derfor til hver en tid en rigtig god rutine. Læs mere om Microsofts .NET release lifecycle.
Mange beslutningstagere er helt uvidende om dette, og derfor hænger rigtig mange .NET-projekter fast i out-of-support versioner (særligt .NET Core 3.1 er stadig udbredt), idet løbende opdatering afhænger af, at menige udviklere i dag tager ansvar for projektets tilstand og produktivitet et år ude i fremtiden. Det vil typisk nemlig være dem, som har den faglige forudsætning for at forstå gevinsten herved, men ofte hverken har beføjelse eller incitament til formelt at føje det til kravspec.
Win-win for alle parter
Løbende projektomkostninger kan dog reduceres markant og fastholdes på et lavt niveau, hvis man sørger for, at .NET-projekter altid er opdateret til nyeste stabile version. Gør man løbende dette, fx i starten eller slutningen af hvert sprint, går de løbende omkostninger for opdateringer mod nul, idet man så, ligesom med unit-testing og diverse DevOps practices, kontinuerligt øger systemets opdaterbarhed, robusthed og generelle kodekvalitet. Samtidig sikrer det udviklernes skarphed på .NET-økosystemets aktuelle tilstand og dermed deres markedsværdi. Det er win-win for alle parter!
Så hvorfor ikke? Fordi opdateringer er et godt eksempel på en "kvadrant 2-aktivitet" (important but not urgent) i den klassiske Eisenhower-matrix, hvor kunsten er, at flytte så meget fokus over i kvadrant 2, at arbejdsmængden i de øvrige kvadranter reduceres over tid – og dermed giver endnu mere overskud til kvadrant 2-fokus: Det er i kvadrant 2, at produktivitet i softwareudvikling øges eksponentielt og konkurrencefordele opdyrkes!
Mange "opgraderings- og migreringsprojekter" kunne helt undgås med ovenstående tilgang. Samme princip gælder i øvrigt også for Angular (se Actively supported Angular versions) og mere eller mindre officielt for de fleste frameworks i dag.
Implications for practice
Har I endnu ikke indarbejdet en sådan opdateringsrutine i jeres kvadrant 2, kan det være lettere sagt end gjort at indføre det nu. For jo mere et projekt sander til i gamle versioner, deprecation-advarsler, komplekse afhængigheder og ikke-opdaterbar kode, mens kvadrant 1-opgaverne hober sig op, jo sværere bliver det at skabe overskud til kvadrant 2.
Læg hertil at de fleste incitamentsstrukturer belønner kvadrant 1-opgaver frem for kvadrant 2-aktiviteter (I belønner forhåbentlig ikke kvadrant 3- og 4-aktiviteter). På den måde bliver sådanne opdateringer på et tidspunkt til en højt prioriteret kvadrant 1-opgave, måske endda et dyrt og komplekst “opgraderings- og migreringsprojekt”. Opfordringen herfra er derfor ikke et “just do it!” – hertil er virkeligheden typisk for kompleks. Men øg opmærksomheden på denne del af den digitale virkelighed, og skab gradvist mere plads til kvadrant 2-aktiviteter.
Læs mere om nyhederne i .NET 8 og C# 12 i de respektive blogindlæg fra folkene bag:
Lars Schunk er Senior Solution Architect hos C Nation.
