Vérification des changements de version Go

Vérification d'une augmentation de version Go

Augmenter la ligne go dans go.mod ne change pas seulement la version du langage. Chaque paquet principal reçoit les valeurs par défaut de GODEBUG de la nouvelle version, de sorte que le comportement dans net/http, crypto/tls, crypto/x509, net/url, runtime et d'autres peut changer sans aucune modification de code. L'outil fourni interroge la chaîne d'outils Go installée pour déterminer quels changements par défaut surviennent et quels binaires importent les paquets concernés. Il nécessite Go installé, lit go.mod sans le modifier, ne compile ni n'exécute jamais le code de l'utilisateur, et n'utilise jamais le réseau.

Exécuter l'outil

Depuis la racine du module, ou en passant son répertoire :

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

• --to par défaut, utilise la version de la chaîne d'outils installée et ne peut pas être plus récent qu'elle. Si l'utilisateur souhaite une cible plus récente, dites-lui qu'il doit d'abord installer cette version de Go.
• --from par défaut, utilise la ligne go actuelle. Pour examiner une PR qui l'a déjà augmentée, passez la version de la branche de base : --from 1.21.
• Ajoutez --json pour une sortie structurée, et --tests pour inclure les binaires de test. Un module sans paquet principal est vérifié automatiquement via ses binaires de test.
• Si l'outil indique que les modules ne sont pas dans le cache des modules, demandez avant d'exécuter go mod download, car cela utilise le réseau.

Vérifier chaque changement qui atteint un binaire

L'outil liste les paramètres par paquet qui les lit. Importer un paquet ne signifie pas que le chemin de code modifié est utilisé, alors vérifiez :

1. Lisez la phrase de documentation et le lien pour le paramètre. Recherchez ensuite dans le code l'API qu'il nomme, par exemple http.NewServeMux et les motifs HandleFunc pour httpmuxgo121, tls.Config pour les paramètres TLS, x509.ParseCertificate ou CreateCertificate pour les paramètres x509, et rand.Seed pour randseednop.
2. Dites pour chaque paramètre si le code utilise ce chemin : utilisé, non utilisé, ou impossible à déterminer (par exemple une dépendance l'appelle).
3. Les paramètres runtime tels que containermaxprocs et updatemaxprocs s'appliquent à chaque binaire. Signalez ceux qui importent selon la façon dont il est déployé, comme les conteneurs avec des limites CPU.
4. Les paramètres commençant par win ne concernent que Windows. Dites-le si le projet n'est pas déployé là-bas.
5. Les paramètres sous « Changes the go command » affectent go test -json ou les builds en CI, pas le programme.

Rapport

1. Un tableau court : paramètre, ce qui change, quels binaires, et si le code utilise ce chemin.
2. Recommandez soit d'adopter le nouveau comportement par défaut, soit d'épingler l'ancien. Ne suggérez d'épingler que pour les paramètres dont le code dépend vraiment, et utilisez le bloc godebug ( ... ) de l'outil. Les épingles sont censées être temporaires : dites qu'elles sont supprimées dans les versions ultérieures de Go.
3. Transmettez les notes de l'outil, comme le changement de variable de boucle de Go 1.22, ou le fait que la ligne go d'une bibliothèque ne définit pas GODEBUG pour les programmes qui l'importent.

Ne pas

• Ne modifiez pas go.mod sauf si l'utilisateur le demande.
• Ne dites pas qu'une augmentation est sûre parce que rien n'est listé. L'outil ne couvre que les valeurs par défaut de GODEBUG. Les notes de version listent d'autres changements.
• N'exécutez pas les tests ou les binaires de l'utilisateur pour vérifier le comportement sauf s'il le demande.