𝗣𝗮𝗰𝗸𝗮𝗴𝗲.𝗷𝘀𝗼𝗻 𝘃𝘀 𝗚𝗼.𝗺𝗼𝗱: 𝗪𝗵𝗲𝗿𝗲 𝗗𝗶𝗱 𝘁𝗵𝗲 𝗩𝗲𝗿𝘀𝗶𝗼𝗻 𝗙𝗶𝗲𝗹𝗱 𝗚𝗼?

𝗣𝗮𝗰𝗸𝗮𝗴𝗲.𝗷𝘀𝗼𝗻 𝘃𝘀 𝗚𝗼.𝗺𝗼𝗱: ¿𝗔 𝗱ó𝗻𝗱𝗲 𝘀𝗲 𝗳𝘂𝗲 𝗲𝗹 𝗰𝗮𝗺𝗽𝗼 𝗱𝗲 𝘃𝗲𝗿𝘀𝗶ó𝗻?

Si pasas de JavaScript a Go, una cosa te sorprenderá.

En un archivo package.json, la versión está justo al principio. Puedes leerla. Puedes cambiarla en un pull request. Puedes buscarla. Es un hecho que vive dentro de tu código.

Ahora abre un archivo go.mod. La versión no está ahí.

Esto no es un error. Es una elección.

Go no utiliza un campo de versión para tu propio módulo. En su lugar, Go utiliza git tags.

Para establecer una versión en Go, haces esto:

• git tag v1.2.3
• git push origin v1.2.3

El git tag es la única fuente de verdad. Cuando alguien ejecuta go get, Go busca en los tags de tu repositorio para encontrar el commit correcto.

Este diseño tiene una gran fortaleza. Una versión nunca puede apuntar al código incorrecto. En npm, el código publicado y el código fuente etiquetado pueden desincronizarse. En Go, son lo mismo porque la versión es un puntero a un commit.

Sin embargo, esto cambia tu flujo de trabajo de varias maneras:

• Encontrar tu versión requiere un comando. Debes ejecutar git describe --tags en lugar de mirar un archivo.
• Los incrementos de versión no aparecen en las revisiones de código. Un push de un tag no es un cambio de código, por lo que no aparece en un pull request.
• Las compilaciones locales utilizan pseudo-versiones. Hasta que etiquetes un commit, verás una larga cadena de números y hashes en lugar de una versión limpia como v1.2.3.
• Las versiones mayores cambian tu ruta de importación. En npm, cambias el número de versión pero mantienes el nombre del paquete. En Go, v2 y superiores requieren un cambio de ruta como /v2. Esto permite que un programa utilice v1 y v2 de la misma librería al mismo tiempo sin conflictos.

La mayoría de los demás ecosistemas mantienen la versión en un archivo:

• Node: package.json
• Rust: Cargo.toml
• Python: pyproject.toml
• Java: pom.xml
• .NET: .csproj

Go es diferente. Depende únicamente de los git tags.

Si quieres que tu binario de Go muestre una versión limpia, puedes inyectarla durante el proceso de compilación usando ldflags. Muchos desarrolladores también utilizan herramientas como goreleaser para automatizar el proceso de etiquetado y lanzamiento.

Los dos modelos representan prioridades diferentes:

• Las versiones basadas en archivos son fáciles de leer y revisar. El riesgo es que el archivo puede desincronizarse del código real.
• Las versiones basadas en tags son imposibles de falsificar. El costo es que son más difíciles de ver y gestionar.

Go eligió el modelo de tags para asegurar que el manifiesto siempre coincida con el código.

Para quienes distribuyen código Go: ¿Cómo les resulta el modelo basado únicamente en etiquetas en su trabajo diario? ¿Lo cambiarían?

Fuente: https://dev.to/dalirnet/packagejson-vs-gomod-where-did-the-version-field-go-3301