GillMacedo/checking-go-version-bumps

Überprüfung eines Go-Version-Bumps

Das Erhöhen der go-Zeile in go.mod ändert mehr als nur die Sprachversion. Jedes Hauptpaket erhält die GODEBUG-Standardwerte der neuen Version, sodass sich das Verhalten in net/http, crypto/tls, crypto/x509, net/url, runtime und anderen ohne Codeänderung ändern kann. Das gebündelte Tool fragt die installierte Go-Toolchain, welche Standardwerte sich ändern und welche Binaries die betroffenen Pakete importieren. Es benötigt eine installierte Go-Installation, liest die go.mod ohne sie zu bearbeiten, baut oder führt den Benutzercode nie aus und verwendet niemals das Netzwerk.

Das Tool ausführen

Vom Modulverzeichnis aus oder durch Angabe des Verzeichnisses:

go run "${CLAUDE_PLUGIN_ROOT}/scripts/godebugdiff.go" --to 1.24 .

• --to standardmäßig auf die Version der installierten Toolchain und kann nicht neuer als diese sein. Wenn der Benutzer ein neueres Ziel wünscht, sagen Sie, dass er zuerst diese Go-Version installieren muss.
• --from standardmäßig auf die aktuelle go-Zeile. Um einen PR zu überprüfen, der sie bereits erhöht hat, geben Sie die Version des Basis-Branches an: --from 1.21.
• Fügen Sie --json für strukturierte Ausgabe und --tests hinzu, um Test-Binaries einzuschließen. Ein Modul ohne Hauptpaket wird automatisch über seine Test-Binaries geprüft.
• Falls angezeigt wird, dass Module nicht im Modul-Cache sind, fragen Sie vor der Ausführung von go mod download, da dies das Netzwerk nutzt.

Jede Änderung prüfen, die eine Binary erreicht

Das Tool listet Einstellungen nach dem Paket auf, das sie liest. Das Importieren eines Pakets bedeutet nicht, dass der geänderte Codepfad verwendet wird. Prüfen Sie daher:

1. Lesen Sie den Dokumentsatz und den Link für die Einstellung. Suchen Sie dann im Code nach der genannten API, wie z.B. http.NewServeMux und HandleFunc-Muster für httpmuxgo121, tls.Config für TLS-Einstellungen, x509.ParseCertificate oder CreateCertificate für x509-Einstellungen und rand.Seed für randseednop.
2. Sagen Sie für jede Einstellung, ob der Code diesen Pfad verwendet: verwendet, nicht verwendet, oder nicht feststellbar (z.B. ein Dependency ruft ihn auf).
3. runtime-Einstellungen wie containermaxprocs und updatemaxprocs gelten für jede Binary. Weisen Sie auf solche hin, die für die Bereitstellung wichtig sind, wie Container mit CPU-Limits.
4. Einstellungen, die mit win beginnen, betreffen nur Windows. Sagen Sie dies, wenn das Projekt nicht dorthin ausgeliefert wird.
5. Einstellungen unter „Änderungen am go-Befehl“ betreffen go test -json oder Builds in CI, nicht das Programm.

Bericht

1. Eine kurze Tabelle: Einstellung, was sich ändert, welche Binaries und ob der Code diesen Pfad verwendet.
2. Empfehlen Sie entweder die Übernahme des neuen Standards oder das Beibehalten des alten. Schlagen Sie das Beibehalten nur für Einstellungen vor, von denen der Code wirklich abhängt, und verwenden Sie den godebug ( ... )-Block des Tools. Beibehaltene Einstellungen sind als temporär gedacht: Sagen Sie, dass sie in späteren Go-Versionen entfernt werden.
3. Geben Sie die Hinweise des Tools weiter, z.B. die Go 1.22-Schleifenvariablenänderung oder dass die go-Zeile einer Bibliothek kein GODEBUG für die Programme setzt, die sie importieren.

Nicht tun

• Bearbeiten Sie go.mod nicht, es sei denn, der Benutzer fragt danach.
• Sagen Sie nicht, dass ein Bump sicher ist, weil nichts gelistet wird. Das Tool deckt nur GODEBUG-Standardwerte ab. Versionshinweise listen andere Änderungen auf.
• Führen Sie die Tests oder Binaries des Benutzers nicht aus, um das Verhalten zu überprüfen, es sei denn, er fragt danach.