Schwere: mittel · Dimension: maintenance
Ausgangslage
Die Patch- und Minor-Bumps sind nachgezogen (#266), verifiziert über die volle lokale Testsuite. Die Majors wurden bewusst ausgelassen — jeder von ihnen berührt etwas, das der Testlauf allein nicht abdeckt.
Was aussteht
Microsoft.CodeAnalysis.CSharp 4.8.0 → 5.6.0 und Microsoft.CodeAnalysis.Analyzers 3.11.0 → 5.6.0.
Directory.Packages.props begründet die 4.8.0 ausdrücklich: „targets a broadly compatible Roslyn; analyzers bind to the host compiler, not this version." Ein Sprung auf 5.6.0 hebt die Mindestanforderung an den Compiler, gegen den Callora.Analyzers läuft — das trifft nicht dieses Repository, sondern jeden, der ein Plugin damit baut. Zu prüfen ist, welche SDK-Version die Analyzer danach voraussetzen und ob das mit der Zusage an Plugin-Autoren zusammenpasst.
Microsoft.CodeAnalysis.PublicApiAnalyzers 4.14.0 → 5.6.0.
Bewacht das Baseline-Gate, das jede Änderung der öffentlichen Fläche zu einem reviewbaren Diff macht. Ein Verhaltenswechsel im Analyzer heißt im besten Fall neue Einträge in PublicAPI.Unshipped.txt, im schlechtesten ein Gate, das anders schneidet als vorher.
Microsoft.OpenApi 2.10.0 → 3.10.0.
Der Eintrag existiert als Sicherheits-Pin: „Pin transitive Microsoft.OpenApi above the vulnerable 2.0.0 (GHSA-v5pm-xwqc-g5wc)." Ein Major-Sprung muss den Pin-Zweck erhalten und die von Microsoft.AspNetCore.OpenApi erwartete Version treffen.
ModelContextProtocol.AspNetCore 1.4.1 → 2.2.0.
Darauf sitzt die gesamte MCP-Werkzeugfläche: McpToolRegistry mutiert die McpServerPrimitiveCollection<McpServerTool>, die der Server ausliefert, und ContributedMcpTool umhüllt jede Plugin-Registrierung. Ein Major am SDK trifft beide Typen direkt. Ein Integrationstest, der eine Werkzeugliste tatsächlich über HTTP abruft, wäre die Absicherung — heute prüft nichts den Weg von der Plugin-Aktivierung bis zur ausgelieferten Werkzeugliste.
Frontend-Majors aus den offenen Dependabot-PRs: TypeScript 5 → 7, Vite 6 → 8, vue-router 4 → 5, vue-tsc 2 → 3, @vitejs/plugin-vue 5 → 6. Die Frontend-Suiten laufen eigenständig und sind nicht Teil von dotnet test; sie brauchen einen eigenen Durchgang.
Randbedingung
Die GitHub-Actions-Läufe starten derzeit nicht (Billing-Zustand des Kontos), und main war deshalb rot, ohne dass ein Job je begonnen hätte. Solange das so ist, ist jeder dieser Sprünge nur lokal prüfbar — was für die .NET-Seite geht, für die Frontend-Matrix aber schlechter. Das spricht dafür, die Majors erst anzugehen, wenn die CI wieder gegenprüfen kann.
Schwere: mittel · Dimension: maintenance
Ausgangslage
Die Patch- und Minor-Bumps sind nachgezogen (#266), verifiziert über die volle lokale Testsuite. Die Majors wurden bewusst ausgelassen — jeder von ihnen berührt etwas, das der Testlauf allein nicht abdeckt.
Was aussteht
Microsoft.CodeAnalysis.CSharp4.8.0 → 5.6.0 undMicrosoft.CodeAnalysis.Analyzers3.11.0 → 5.6.0.Directory.Packages.propsbegründet die 4.8.0 ausdrücklich: „targets a broadly compatible Roslyn; analyzers bind to the host compiler, not this version." Ein Sprung auf 5.6.0 hebt die Mindestanforderung an den Compiler, gegen denCallora.Analyzersläuft — das trifft nicht dieses Repository, sondern jeden, der ein Plugin damit baut. Zu prüfen ist, welche SDK-Version die Analyzer danach voraussetzen und ob das mit der Zusage an Plugin-Autoren zusammenpasst.Microsoft.CodeAnalysis.PublicApiAnalyzers4.14.0 → 5.6.0.Bewacht das Baseline-Gate, das jede Änderung der öffentlichen Fläche zu einem reviewbaren Diff macht. Ein Verhaltenswechsel im Analyzer heißt im besten Fall neue Einträge in
PublicAPI.Unshipped.txt, im schlechtesten ein Gate, das anders schneidet als vorher.Microsoft.OpenApi2.10.0 → 3.10.0.Der Eintrag existiert als Sicherheits-Pin: „Pin transitive Microsoft.OpenApi above the vulnerable 2.0.0 (GHSA-v5pm-xwqc-g5wc)." Ein Major-Sprung muss den Pin-Zweck erhalten und die von
Microsoft.AspNetCore.OpenApierwartete Version treffen.ModelContextProtocol.AspNetCore1.4.1 → 2.2.0.Darauf sitzt die gesamte MCP-Werkzeugfläche:
McpToolRegistrymutiert dieMcpServerPrimitiveCollection<McpServerTool>, die der Server ausliefert, undContributedMcpToolumhüllt jede Plugin-Registrierung. Ein Major am SDK trifft beide Typen direkt. Ein Integrationstest, der eine Werkzeugliste tatsächlich über HTTP abruft, wäre die Absicherung — heute prüft nichts den Weg von der Plugin-Aktivierung bis zur ausgelieferten Werkzeugliste.Frontend-Majors aus den offenen Dependabot-PRs: TypeScript 5 → 7, Vite 6 → 8,
vue-router4 → 5,vue-tsc2 → 3,@vitejs/plugin-vue5 → 6. Die Frontend-Suiten laufen eigenständig und sind nicht Teil vondotnet test; sie brauchen einen eigenen Durchgang.Randbedingung
Die GitHub-Actions-Läufe starten derzeit nicht (Billing-Zustand des Kontos), und
mainwar deshalb rot, ohne dass ein Job je begonnen hätte. Solange das so ist, ist jeder dieser Sprünge nur lokal prüfbar — was für die .NET-Seite geht, für die Frontend-Matrix aber schlechter. Das spricht dafür, die Majors erst anzugehen, wenn die CI wieder gegenprüfen kann.