GillMacedo/checking-go-version-bumps

Comprobación de un aumento de versión de Go

Elevar la línea go en go.mod cambia más que la versión del lenguaje. Cada paquete principal obtiene los valores predeterminados de GODEBUG de la nueva versión, por lo que el comportamiento en net/http, crypto/tls, crypto/x509, net/url, runtime y otros puede cambiar sin modificar el código. La herramienta incluida pregunta a la cadena de herramientas Go instalada qué valores predeterminados cambian y qué binarios importan los paquetes afectados. Necesita Go instalado, lee go.mod sin editarlo, nunca compila ni ejecuta el código del usuario, y nunca usa la red.

Ejecutar la herramienta

Desde la raíz del módulo, o pasa su directorio:

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

• --to por defecto es la versión de la cadena de herramientas instalada y no puede ser más nueva que ella. Si el usuario quiere un destino más reciente, dile que primero necesita instalar esa versión de Go.
• --from por defecto es la línea go actual. Para revisar un PR que ya la haya subido, pasa la versión de la rama base: --from 1.21.
• Añade --json para obtener una salida estructurada, y --tests para incluir binarios de prueba. Un módulo sin paquete principal se verifica automáticamente a través de sus binarios de prueba.
• Si dice que los módulos no están en la caché de módulos, pregunta antes de ejecutar go mod download, ya que eso usa la red.

Verificar cada cambio que alcanza un binario

La herramienta enumera las configuraciones por el paquete que las lee. Importar un paquete no significa que se use la ruta de código modificada, así que verifica:

1. Lee la frase de documentación y el enlace de la configuración. Luego busca en el código la API que nombra, como http.NewServeMux y los patrones HandleFunc para httpmuxgo121, tls.Config para configuraciones TLS, x509.ParseCertificate o CreateCertificate para configuraciones x509, y rand.Seed para randseednop.
2. Di para cada configuración si el código usa esa ruta: usada, no usada, o no se puede determinar (por ejemplo, una dependencia la llama).
3. Las configuraciones de runtime como containermaxprocs y updatemaxprocs aplican a todos los binarios. Señala las que importen según cómo se despliega, como contenedores con límites de CPU.
4. Las configuraciones que empiezan con win solo importan en Windows. Dilo si el proyecto no se distribuye allí.
5. Las configuraciones bajo "Cambia el comando go" afectan a go test -json o a compilaciones en CI, no al programa.

Informe

1. Una tabla corta: configuración, qué cambia, qué binarios, y si el código usa esa ruta.
2. Recomienda ya sea adoptar el nuevo valor predeterminado o fijar el antiguo. Solo sugiere fijar configuraciones de las que el código realmente depende, y usa el bloque godebug ( ... ) de la herramienta. Las fijaciones están pensadas para ser temporales: di que se eliminan en versiones posteriores de Go.
3. Transmite las notas de la herramienta, como el cambio de variable de bucle en Go 1.22, o que la línea go de una biblioteca no establece GODEBUG para los programas que la importan.

No hacer

• No edites go.mod a menos que el usuario lo pida.
• No digas que una subida es segura porque no se lista nada. La herramienta solo cubre los valores predeterminados de GODEBUG. Las notas de la versión listan otros cambios.
• No ejecutes las pruebas o binarios del usuario para verificar el comportamiento a menos que lo pida.