Prácticas recomendadas para el historial y las versiones de Go
Un resumen condensado de las 25 prácticas más importantes de lanzamiento y actualización de Go, extraídas de cada página de esta sección.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 prácticas más importantes de lanzamiento y actualización de Go, extraídas de cada página de esta sección.
Lea primero las notas de lanzamiento: Revise go.dev/doc/go1.N antes de editar go.mod; las secciones de tiempo de ejecución y criptografía afectan a la producción sin diferencias de código fuente.
Programe revisiones semestrales: Alinee la planificación de actualizaciones con las versiones menores de febrero y agosto, incluso si omite algunas versiones.
Fije CI en los registros de go version: Cada pipeline imprime la versión del compilador para la correlación de incidentes.
Separe la toolchain de la versión del lenguaje: GOTOOLCHAIN=auto puede compilar con 1.26 mientras los módulos aún declaran go 1.24 durante las implementaciones graduales.
Actualice las bibliotecas antes que los servicios: Los módulos compartidos libs/* se actualizan primero para que los importadores hereden las API probadas.
Retrase las bibliotecas publicadas una versión menor: Los módulos públicos mantienen una mayor compatibilidad con los consumidores cuando las directivas go van por detrás de las aplicaciones.
Use go.work en monorepos: Prefiera los espacios de trabajo sobre las directivas replace confirmadas para el desarrollo local de múltiples módulos.
Ejecute go work sync: Mantenga alineadas las líneas go/toolchain del espacio de trabajo y del módulo después de cada actualización.
Ejecute go mod tidy en CI: Detecte entradas require obsoletas y entradas go.sum faltantes en cada PR de actualización.
Considere go fix como obligatorio: Los modernizadores de Go 1.26 son parte de la actualización, no una limpieza opcional.
Ejecute go fix dos veces: Los analizadores sinérgicos y la limpieza de importaciones a menudo necesitan un segundo pase en repositorios grandes.
Previsualice con go fix -diff: Revise el alcance de la modernización antes de que los revisores se enfrenten a sorpresas de mil líneas.
Mantenga vet en la puerta de enlace: Los nuevos analizadores de go vet exponen errores latentes; pasar la compilación no es suficiente.
Regenere después de las actualizaciones: Protobuf, mocks y las salidas de go generate deben coincidir con la nueva toolchain.
Valide Green Tea GC en canary: Go 1.26 utiliza Green Tea por defecto; compare la CPU de GC y p99 antes de la promoción completa.
Documente la reversión de GOEXPERIMENT: Escriba de antemano los pasos de reconstrucción de nogreenteagc; la exclusión es temporal hasta 1.27.
Rastree las anulaciones de GODEBUG: Inventar las variables de entorno de producción; anote los plazos de eliminación de las notas de lanzamiento.
Pruebe la matriz de clientes TLS: Los valores predeterminados de criptografía cambian el comportamiento del handshake para los clientes heredados sin ediciones de código.
Actualice los perfiles PGO trimestralmente: La optimización guiada por producción solo ayuda cuando los perfiles coinciden con el tráfico.
Ejecute govulncheck en las ramas de actualización: Empareje las correcciones de seguridad de las notas de lanzamiento con el análisis de alcanzabilidad.
Escriba ADRs de actualización: Capture el orden de los módulos, las puertas de enlace, las métricas y los comandos de reversión antes de comenzar el trabajo de staging.
Pruebe en canary al 5-10% con salvaguardas SLO: Pruebe con tráfico pico; los cambios en GC necesitan una carga representativa.
Siga las propuestas, no el folclore de Go 2: El estado de las características se encuentra en go.dev/issue; la entrega incremental es política.
Enseñe la historia para dar contexto: Los orígenes y la promesa de compatibilidad explican por qué Go evita lanzamientos que rompan el semver.
Elimine las exclusiones temporales según lo programado: Elimine nogreenteagc y el GODEBUG heredado una vez que expiren los plazos de validación.
Muchos equipos apuntan a hacerlo dentro de 1-2 meses después de cada lanzamiento de febrero/agosto.
Los entornos regulados pueden retrasarse más con una aceptación de riesgos documentada.
Ejecute en ramas de actualización dedicadas con revisión.
Trate la salida como formato: commits intencionales y probados.
Verifique los objetivos de la placa y los tiempos de ejecución de wasm de forma independiente en el momento de la compilación.
Siguen ciclos de lanzamiento relacionados pero separados de la toolchain principal.
Revisión estructurada de las notas de lanzamiento con los propietarios de tiempo de ejecución y criptografía asignados antes de cualquier actualización de go.mod.
Versiones de la pila: Esta página fue escrita para Go 1.26.x (Green Tea GC por defecto, modernizadores de go fix - verifique el parche en la compilación), chi (última versión - verifique en la compilación), gin (última versión - verifique en la compilación), echo (última versión - verifique en la compilación), google.golang.org/grpc (última versión - verifique en la compilación), sigs.k8s.io/controller-runtime (última versión - verifique en la compilación), kubebuilder (última versión - verifique en la compilación), tinygo (última versión - verifique los objetivos de la placa en la compilación), wazero (última versión - verifique en la compilación) y golangci-lint (última versión - verifique el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 19 jul 2026